16:07:44 <dgilmore> #startmeeting FESCO (2016-08-26)
16:07:44 <zodbot> Meeting started Fri Aug 26 16:07:44 2016 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:07:44 <zodbot> The meeting name has been set to 'fesco_(2016-08-26)'
16:07:45 <dgilmore> #meetingname fesco
16:07:45 <zodbot> The meeting name has been set to 'fesco'
16:07:45 <dgilmore> #chair maxamillion dgilmore jwb nirik paragan jsmith kalev sgallagh Rathann
16:07:45 <zodbot> Current chairs: Rathann dgilmore jsmith jwb kalev maxamillion nirik paragan sgallagh
16:07:48 <dgilmore> #topic init process
16:08:01 <sgallagh> .hello sgallagh
16:08:01 <jsmith> .hellomynameis jsmith
16:08:02 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:08:04 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
16:08:09 <kalev> .hello kalev
16:08:10 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:08:12 <nirik> .hello kevin
16:08:16 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
16:08:21 <paragan> .hello pnemade
16:08:22 <Rathann> .hello rathann
16:08:22 <zodbot> paragan: pnemade 'Parag Nemade' <pnemade@redhat.com>
16:08:25 <zodbot> Rathann: rathann 'Dominik Mierzejewski' <dominik@greysector.net>
16:08:36 <maxamillion> .hello maxamillion
16:08:37 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:09:48 <dgilmore> lets get started
16:10:00 <dgilmore> #topic #1609 Fedora 26 schedule proposal
16:10:00 <dgilmore> .fesco 1609
16:10:00 <dgilmore> https://fedorahosted.org/fesco/ticket/1609
16:10:02 <zodbot> dgilmore: #1609 (Fedora 26 schedule proposal) – FESCo - https://fedorahosted.org/fesco/ticket/1609
16:10:15 <nirik> I guess we didn't discuss this anymore in ticket. ;(
16:10:29 <dgilmore> I have to agree with jwb we should not shorted the mass rebuild window
16:10:59 <jsmith> I've said my peace... and defer to rel-eng on the length of the mass rebuild
16:11:00 <dgilmore> shorten
16:11:24 <dgilmore> jsmith: you said it where?
16:11:39 * jwb is here now
16:12:06 <dgilmore> jsmith: I am unaware of what you said. and it is not in the ticket
16:12:50 <jsmith> dgilmore: In last week's meeting
16:12:56 <dgilmore> jwb: we are working out a couple of issues with the moonshot chasis, as soon as that is resolved, we will be working to bring in aarch64
16:12:58 <nirik> dgilmore: you didn't want branching and bodhi activation on the same day right? (There was a proposal to do that last time I think)
16:13:07 <dgilmore> nirik: right
16:13:17 <dgilmore> nirik: we used to do that and it is just too much work
16:13:18 <nirik> but 1 week would be ok for that? or ?
16:13:27 <dgilmore> 1 week is fine
16:13:27 <jwb> dgilmore: yep.  pbrobinson is keeping me in the loop there
16:13:50 <nirik> adamw wants gpg checking to follow that too... ie, not be 1 until bodhi activation point.
16:14:01 <kalev> could bodhi activation be a day later, not a week later?
16:14:11 <dgilmore> kalev: not really
16:14:18 <dgilmore> kalev: maybe 2 or 3 days later
16:14:26 * kalev nods.
16:14:33 <dgilmore> kalev: there is a lot of small pieces in there
16:14:46 <dgilmore> it takes a bit to shake out
16:14:59 <dgilmore> nirik: well hopefull autosigning will be in place
16:15:02 <nirik> so, we could make it on thursday of the alpha activation week (where thats tuesday)?
16:15:12 <nirik> dgilmore: well, we can hope. ;)
16:15:15 <dgilmore> nirik: we could
16:17:36 <nirik> so, we need to have a new proposal with all this mixed in.
16:17:42 <dgilmore> nirik: yeah
16:17:43 <nirik> not sure about gcc
16:18:04 <dgilmore> we should ask jakub
16:18:14 <nirik> law chimed in there...
16:18:16 <nirik> in ticket.
16:18:17 <sgallagh> nirik: They specifically told us January 25th
16:18:32 <nirik> sgallagh: nope, actually not
16:18:44 <sgallagh> Before that, they wouldn't recommend mass rebuilding as the likelihood of code generation issues would be too high
16:18:46 <sgallagh> nirik: ?
16:18:46 <nirik> they said they did the 25th for f24 with a bunch of scrambling
16:18:56 <Rathann> yes, he said "What makes a lot more sense is to have a go/no go by say Jan 30."
16:19:05 <nirik> yeah, so, jan 31st
16:19:06 <dgilmore> gcc and glibc seem to be best with mass rebuild in feb
16:19:32 <sgallagh> OK, I must have misread.
16:19:34 <sgallagh> Well, crap
16:19:44 <dgilmore> and we really need 3 weeks
16:19:56 <dgilmore> so I would say GA should be June 6
16:21:00 <sgallagh> So should we just go ahead and declare today that odd-numbered Fedoras will be longer cycles and even-numbered ones short?
16:21:03 <nirik> how about someone propose dates based on all this in ticket and we visit next week, which would allow gcc/glibc or whoever to weigh in.
16:21:20 <dgilmore> nirik: sounds good
16:21:37 <nirik> sgallagh: sure sounding like thats going to be the case. ;(
16:23:22 <dgilmore> does anyone want to put together a proposed schedule??
16:23:46 <jsmith> sgallagh: I'm fine with that, personally :-)
16:23:48 <sgallagh> I guess I'll do it; I created the other proposed ones.
16:24:25 <dgilmore> #action sgallagh to put together a proposed schedule with mass rebuild in Feb for 3 weeks and release on June 6th
16:24:35 * Rathann is trying to get the hang of making tables in trac
16:24:42 <dgilmore> #topic #1613 Deletion of EOL AMIs
16:24:42 <dgilmore> .fesco 1613
16:24:43 <zodbot> dgilmore: #1613 (Deletion of EOL AMIs) – FESCo - https://fedorahosted.org/fesco/ticket/1613
16:24:44 <dgilmore> https://fedorahosted.org/fesco/ticket/1613
16:24:47 <sgallagh> Rathann: I just copied and pasted from earlier comments :-D
16:24:52 <Rathann> heh
16:25:21 <dgilmore> not sure we have a resolution on the aws account yet
16:25:40 <nirik> this was waiting on that... yeah. perhaps remove meeting keyword until there is news?
16:25:51 <dgilmore> yeah
16:25:52 <jsmith> That works for me
16:26:09 <dgilmore> #info remove meeting keywork until we have the account issues resolved
16:26:36 <sgallagh> (Quick question on F25: do we want to extend the Change Submission date by a week if we're moving out the rebuild?)
16:26:48 <dgilmore> sgallagh: no
16:27:18 <dgilmore> sgallagh: but i assume you mean f26
16:27:49 <nirik> well, why not?
16:28:04 <dgilmore> i would rather changes be in sooner
16:28:35 <sgallagh> dgilmore: Right, F26
16:28:40 <jwb> no
16:28:46 <jwb> no to extending it
16:28:55 <sgallagh> I'll leave that piece of the proposal alone for now. We can discuss it once it's up
16:29:03 <sgallagh> /me stops sidetracking
16:29:04 <dgilmore> okay
16:29:06 <dgilmore> #topic #1614 FHS exception for /snap
16:29:07 <dgilmore> .fesco 1614
16:29:08 <dgilmore> https://fedorahosted.org/fesco/ticket/1614
16:29:09 <zodbot> dgilmore: #1614 (FHS exception for /snap) – FESCo - https://fedorahosted.org/fesco/ticket/1614
16:29:13 <nirik> I guess... seems like it doesn't matter too much before the other steps, but ok
16:29:32 * jsmith doesn't really care...
16:29:34 <Pharaoh_Atem> did maxamillion get in touch with folks from other distros about this?
16:29:38 <nirik> maxamillion: any news?
16:29:39 <jsmith> I guess I'm OK with it
16:30:18 <tibbs> BTW, if we're going to do an exception, can we please do one that isn't specific to any one piece of software?
16:30:31 <maxamillion> I tried, no response :/
16:30:47 <maxamillion> I sent emails to people from debian and opensuse, I even re-ping'd about mid-week and still no response
16:30:51 <tibbs> I mean, does flatpak get its own root directory too?
16:30:59 <Pharaoh_Atem> for what it's worth, upstream is now working on making it possible to move /snap to another location
16:31:07 <maxamillion> tibbs: not to the best of my knowledge, no
16:31:11 <Pharaoh_Atem> I suggested /var/lib/snapd/snaprun, and I think zyga is going with that
16:31:13 <jsmith> Pharaoh_Atem, that's good...
16:31:15 <maxamillion> Pharaoh_Atem++
16:31:23 <Pharaoh_Atem> maxamillion: use my fas name
16:31:32 <nirik> tibbs: it doesn't.
16:31:41 <maxamillion> Pharaoh_Atem: what's your fas name? :)
16:31:43 <jsmith> If that's the case, I'm more inclined to be +0 or -1 on this...
16:31:44 <Pharaoh_Atem> maxamillion: ngompa
16:31:45 <tibbs> That was actually an example.
16:31:47 <maxamillion> ngompa++
16:31:48 <zodbot> maxamillion: Karma for ngompa changed to 3 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:31:49 <maxamillion> \o/
16:31:59 <dgilmore> tibbs: flatpak puts stuff in /opt
16:32:00 <maxamillion> jsmith: +1
16:32:08 <Pharaoh_Atem> geez, just realized that zodbot still thinks it's f24
16:32:13 <maxamillion> dgilmore: really? ... ugh :/
16:32:17 <nirik> dgilmore: ? no
16:32:18 <dgilmore> maxamillion: yep
16:32:25 <Pharaoh_Atem> dgilmore: ugh
16:32:25 <nirik> dgilmore: what stuff?
16:32:26 <tibbs> /opt is OK if they went through lanananana or whatever it is to get an identifier.
16:32:26 <dgilmore> and it needs the rpms to be rebuilt
16:32:42 <Pharaoh_Atem> so... why don't we use the relocation feature in rpm with this?
16:32:46 <nirik> Pharaoh_Atem: it is the f24 release cycle. f24 is released.
16:32:53 <dgilmore> nirik: everything for flatpak is in /opt
16:32:57 <nirik> dgilmore: not here.
16:33:05 <nirik> I have nothing but google junk in /opt
16:33:16 <nirik> it uses /var/lib/flatpak
16:33:19 <Pharaoh_Atem> having random crap in /opt is not okay
16:33:37 <dgilmore> nirik: that what I have talked about with them
16:33:37 <maxamillion> nirik: +1
16:34:01 <nirik> it wouldn't have passed review with /opt usage.
16:34:15 <Pharaoh_Atem> I get the feeling people don't actually *know* you can't do this
16:34:21 <Pharaoh_Atem> because vdsm had a similar problem
16:34:23 <maxamillion> nirik++
16:34:27 <Pharaoh_Atem> err, has
16:34:33 <jsmith> nirik++
16:34:33 <zodbot> jsmith: Karma for kevin changed to 20 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:34:33 <tibbs> We do have guidelines for /opt, and there's a registry for stuff under it.
16:34:53 <dgilmore> nirik: sorry https://fedoraproject.org/wiki/Workstation/BuildingFlatpaks?rd=Workstation/BuildingXdgApps /app not /opt
16:34:58 <nirik> right, there's also someone on the epel list that wants to bring in newer gcc/tools and they package them under /opt
16:35:08 <tibbs> https://fedoraproject.org/wiki/Packaging:Guidelines#Limited_usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt
16:35:10 <Pharaoh_Atem> vdsm is using /rhev without telling anyone
16:35:30 <dgilmore> Pharaoh_Atem: they are fixing that
16:35:40 <nirik> dgilmore: thats in the bind/runtime... not on the installed system
16:35:43 <jwb> can we get back on track?
16:35:44 <dgilmore> moving to /run/
16:35:59 <dgilmore> so snaps
16:36:03 <Rathann> Pharaoh_Atem: it's a violation of the FPG, then
16:36:11 <nirik> and I think that page could well be out of date
16:36:13 <dgilmore> I think we need to defer a week for maxamillion to further investigate
16:36:19 * Rathann goes to file a bug
16:36:38 <dgilmore> Rathann: for what?>
16:36:55 <Rathann> for vdsm using /rhev
16:37:00 <Pharaoh_Atem> snapd has one remaining PR to fix it: https://github.com/snapcore/snapd/pull/1745
16:37:03 <dgilmore> Rathann: there is alrteady one
16:37:21 <Rathann> dgilmore: no, there isn't one open
16:37:30 <Pharaoh_Atem> as far as I know, after this is done, upstream will make a release next week of snapd and snap-confine with a configurable location
16:37:33 <nirik> +1 for waiting a week
16:37:46 <Pharaoh_Atem> so I'm okay with delaying this a week
16:37:55 <dgilmore> Rathann: they asked me about it this week
16:37:58 <Pharaoh_Atem> that way maxamillion can poke with sharp pointy sticks
16:38:01 <maxamillion> +1 to waiting a week, I'm hoping I can get some more responses
16:38:02 <dgilmore> Rathann: but it is currently off topic
16:38:10 <maxamillion> or some at all really
16:38:12 <Rathann> right
16:38:24 <maxamillion> thanks to Pharaoh_Atem for providing information and keeping up with upstream
16:38:34 <dgilmore> #info maxamillion to investigate more, reevaluate next week
16:38:58 <dgilmore> everyone okay to move on?
16:39:09 <maxamillion> +1
16:39:12 <paragan> yes
16:39:16 <Rathann> yes
16:39:17 <dgilmore> #topic #1617    Council update on Third Party Software policy
16:39:18 <dgilmore> .fesco 1617
16:39:18 <dgilmore> https://fedorahosted.org/fesco/ticket/1617
16:39:19 <zodbot> dgilmore: #1617 (Council update on Third Party Software policy) – FESCo - https://fedorahosted.org/fesco/ticket/1617
16:39:36 * nirik proposed some wording there, changes welcome
16:40:41 <maxamillion> nirik: I liked the proposed changes
16:40:45 <Sir_Gallantmon> Just as an aside, I'm not happy with the general attitude in the proposed policy
16:40:52 <jsmith> I'm also fine with nirik's language
16:40:57 <maxamillion> Sir_Gallantmon: how so?
16:41:05 <paragan> wording looks good to me but wanted to know more about dnf usage with non-free
16:41:28 <jwb> paragan: i asked mattdm to follow up on your question.  he's working with aday and can probably answer better from an implementation standpoint
16:41:29 <sgallagh> Sir_Gallantmon: This is the wrong venue for that discussion. The Council makes decisions based on policy, FESCo decides how to implement it
16:41:40 <nirik> paragan: I suppose someone could file a RFE on dnf... but right now, you are just out of luck from there. Just like you are for say offline updates.
16:42:16 <paragan> jwb, thanks
16:42:16 <sgallagh> nirik: I think your wording is fine to move ahead with. If it needs tweaking down the road... we'll tweak it down the road.
16:42:23 <paragan> nirik, then let's wait for any update
16:42:52 <sgallagh> paragan: I'd prefer to provide something that the GNOME folks can move ahead with for now
16:43:03 <sgallagh> And amend the policy if needed to support other mechanisms
16:43:11 <jwb> sgallagh: agreed
16:43:25 <dgilmore> I am guessing that the implementation will depend on metadata_enabled, which is a repo definition that only is supported in PackageKit/gnome-software
16:43:28 <maxamillion> Proposal: Accept nirik's changes for Third Party Software Policy
16:43:38 <sgallagh> maxamillion: +1
16:43:38 <nirik> dgilmore: yeah.
16:43:42 <maxamillion> +1
16:43:46 <paragan> sgallagh, agree but would like to get some feedback on my query
16:44:12 <sgallagh> paragan: Absolutely. I just don't think we need to burn a week waiting for it :)
16:44:22 <Rathann> +1, I think it sounds fine
16:44:24 <paragan> maxamillion, +1
16:44:31 <kalev> +1
16:44:33 <nirik> +1
16:44:42 <jwb> +1
16:44:48 <jsmith> +1
16:44:53 <dgilmore> +1
16:46:00 <dgilmore> #accepted Accept nirik's changes for Third Party Software Policy (9:+ 0:- 0:0)
16:46:10 * dgilmore thinks that is right
16:46:55 <nirik> sure.
16:47:23 <nirik> Sir_Gallantmon: feel free to share additional concerns on the council ticket or #fedora-devel, #fedora-council if you need to.
16:47:39 <dgilmore> #topic #1619 Sponsorship for packager needs clarification again
16:47:39 <dgilmore> .fesco 1619
16:47:40 <zodbot> dgilmore: #1619 (Sponsorship for packager needs clarification again) – FESCo - https://fedorahosted.org/fesco/ticket/1619
16:47:40 <dgilmore> https://fedorahosted.org/fesco/ticket/1619
16:47:48 <paragan> Please discuss on this ticket for Sponsor policy text only not on the given reference bug
16:48:16 <nirik> I think the bug thing was just miscommunication. Hopefully everyone talked and is back to ok now...
16:48:50 <paragan> yes I am fine as said above
16:49:22 <nirik> that said, we can add those things I listed to the policy, but there is absolutely no way that we can list everything. So, IMHO it's better to just say "sponsors can sponsor anyone anytime they like" and leave it to their judgement. I know we want the review queue down, but sometimes it's not practical to force people to review other packages.
16:49:26 <paragan> Can we have some amendment to existing text to cover more cases?
16:49:35 <maxamillion> given nirik's comments, I'm not sure what's currently missing from the policy
16:50:24 <paragan> maxamillion, I was not clear that a person with single package submission who is also upstream developer can get sponsorship just on that single submission
16:50:26 <sgallagh> I kind of agree with nirik: I'd rather reduce it down to "Sponsors are trusted to make their own decision about when sponsorship is earned" and maybe something about a path to FESCo if someone is abusing it
16:50:32 <jwb> nirik: agreed.
16:50:53 <maxamillion> nirik: +1
16:50:54 <maxamillion> sgallagh: +1
16:50:59 <Rathann> +1
16:51:01 <maxamillion> should we amend the guidelines to say jus thtat?
16:51:02 <maxamillion> that*
16:51:15 <jsmith> I'm +1 for that -- I don't see anyone abusing the process
16:51:34 <dgilmore> +1
16:51:46 <dgilmore> should we have a formal proposal?
16:51:56 <maxamillion> I mostly just don't want to raise the bar for contributions to make it more difficult for newcomers to join, I like to believe we can trust the Sponsors (which is how they became Sponsors in the first place)
16:52:52 * dgilmore will be right back. I need to relocate
16:52:53 <sgallagh> Proposal: Package sponsorship is clarified to be simply "Sponsors are trusted to make their own decision about when sponsorship is earned" and that if someone believes this is being abused, they should file a ticket with FESCo/
16:53:10 <nirik> well, where is that added?
16:53:10 <jwb> +1
16:53:11 <maxamillion> sgallagh: +1
16:53:20 <nirik> the sponsor page has a lot of text...
16:54:08 <paragan> though I still find it not specific
16:54:13 <nirik> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
16:54:19 <paragan> I am okay at least for some change text
16:54:51 <paragan> Also if we think we can trust on Sponsor then why even need to keep other sub sections
16:54:57 <nirik> perhaps a new heading under 'convince someone to sponsor you' and list 'Other' and say sponsors may choose to sponsor you for any other reason they wish.
16:55:05 <jwb> paragan: that's the point.  sponsorship _isn't_ something that is specific
16:55:48 <paragan> Just have a single line in that Policy "Sponsors are trusted to make their own decision about when sponsorship is earned"
16:56:19 <paragan> I am fine with that single line
16:56:20 * dgilmore is relocated
16:56:39 <nirik> proposal: add new section to how to get sponsored page that notes that sponsors can choose to sponsor for any reason, etc
16:56:47 <maxamillion> nirik: +1
16:56:56 <sgallagh> dgilmore: I think that puts you in violation of the packaging guidelines :-P
16:56:56 <kalev> nirik: +1
16:57:00 <dgilmore> nirik: +1
16:57:05 <nirik> ha
16:57:06 <sgallagh> nirik: +1
16:57:08 <dgilmore> sgallagh: ???
16:57:13 <nirik> +1
16:57:23 <sgallagh> dgilmore: "(12:56:20 PM) ***dgilmore is relocated"
16:57:30 <paragan> nirik, +1
16:57:53 <paragan> anything is fine as long as text is getting amended
16:58:01 <jsmith> +1
16:58:07 <dgilmore> sgallagh: sorry I had surgey this week and was i pain and need to move to somewhere more comfortable. and not in the mood for sarcasm
16:58:48 <sgallagh> dgilmore: Sorry to hear it. I wasn't being sarcastic, just making a joke. RE: https://fedoraproject.org/wiki/Packaging:Guidelines#Relocatable_packages
16:59:09 <dgilmore> #accepted  add new section to how to get sponsored page that notes that sponsors can choose to sponsor for any reason, etc (8:+ 0:- 0:0)
17:00:34 <dgilmore> #topic #1620 Decide what to do when package is retired and nothing replaces it
17:00:37 <dgilmore> directly
17:00:39 <dgilmore> .fesco 1620
17:00:41 <zodbot> dgilmore: #1620 (Decide what to do when package is retired and nothing replaces it directly) – FESCo - https://fedorahosted.org/fesco/ticket/1620
17:00:42 <dgilmore> https://fedorahosted.org/fesco/ticket/1620
17:01:10 <dgilmore> this has long been an issue
17:01:40 <sgallagh> I thought we resolved this on upgrades with the switch to --distrosync by default
17:01:53 <dgilmore> sgallagh: why would it be?
17:01:59 <jsmith> I'm fine with either option 2 or 3
17:02:03 <sgallagh> Doesn't that remove packages that aren't known to the repos?
17:02:20 <kalev> I think we have a partial solution for that already: dnf/PackageKit distro upgrades and the free standing dnf --allowerasing flag can make the depsolvers remove packages on upgrades if it can't otherwise resolve the transaction
17:02:32 <nirik> we long ago (extras days?) talked about a metapackage for these... and decided not to do that.
17:02:41 <dgilmore> sgallagh: no
17:02:46 <sgallagh> 3) doesn't work; it's too complicated to maintain (see many fedup issues)
17:02:53 <Rathann> nirik: tibbs mentioned that ;)
17:03:15 <sgallagh> nirik: Yeah, apparently eight years ago according to tibbs
17:03:20 * nirik nods
17:03:23 <tibbs> Something like that.
17:03:24 <dgilmore> sgallagh: I wet to do distro-sync from f23 to f25 this morning on a machine and dnf-langpacks were broken
17:03:52 <tibbs> I could hear the laughter through the network cable, but times change…
17:04:02 <Rathann> I, for one, think upgrades should be allowed to fail and the user should be asked if they want to autoremove problematic packages and retry
17:04:32 * nirik isn't a fan of any solution here. ;(
17:04:49 <sgallagh> Problems I can foresee with that metapackage: unretirement or name-reuse would be a pain in the neck, as would the ever-growing metadata on that package.
17:04:52 <jwb> nirik: nor i.  mostly because i think it's a case by case basis anyway
17:05:07 <tibbs> I'm thinking that having the single package which obsoletes things but which isn't necessarily installed by default at least gives the end user a switch they can turn on or off.
17:05:27 <kalev> we could maybe put a list of blocked packages into yum metadata and then dnf could remove those on distro upgrades
17:05:30 <sgallagh> tibbs: If it's not installed by default, it is basically useless
17:05:33 <nirik> if it's not installed by default it wouldn't help tho?
17:05:36 <sgallagh> I'd make it opt-out, if anything
17:05:54 <tibbs> But note that it _still_ won't cover the solution of third party repos, or packages that you just download from somewhere.
17:06:08 <jwb> guys, i think trying to engineer a solution here is admirable but perhaps not time well spent.
17:06:18 <dgilmore> jwb: indeed
17:06:19 <Rathann> exactly, hence the distro upgrade tools should handle this gracefully
17:06:35 <dgilmore> Rathann: there is no one right answer
17:06:43 <Rathann> I know
17:06:52 <Rathann> it's what I said in the ticket, too
17:07:31 <nirik> I guess I agree with jwb... its case by case. In the case of dnf-langpacks, what took over that? it should obsolete it...
17:07:52 <tibbs> adamwill wanted FPC to provide the right answer.  All we could do from our end is suggest a packaging thing.
17:07:52 <Rathann> but if the tools do handle such cases, the user is not left wondering what to do
17:08:24 <Pharaoh_Atem> we do the metapackage thing for that in Mageia
17:08:36 <Pharaoh_Atem> we have a task-obsolete package that has those for being able to do upgrades
17:09:11 <Pharaoh_Atem> while it works, it requires people having the ability to freely edit package sources
17:09:20 <Pharaoh_Atem> while this is the norm in Mageia, this is not the case in Fedora
17:09:34 <Pharaoh_Atem> I don't even know if the Fedora tooling allows such a case
17:10:08 <nirik> a metapackage would be error prone, need constant tending and also take away the choice from the user in some cases.
17:10:10 <sgallagh> Pharaoh_Atem: If we wanted that to happen, it wouldn't be too hard
17:10:15 * jsmith has a hard stop in five minutes :-/
17:10:38 <Pharaoh_Atem> the other bit is regularly culling it
17:10:42 <kalev> I put an alternative proposal in the ticket
17:10:44 <Pharaoh_Atem> we reset task-obsolete after a release
17:10:49 <Pharaoh_Atem> Fedora would do it after two
17:11:35 <nirik> kalev: would need to run it by dnf maintainers for feasability... and createrepo
17:11:37 <Pharaoh_Atem> but the biggest thing is that everyone would have to be diligent about it
17:11:51 <dgilmore> kalev: that would make already too big metadata bigger
17:12:09 <paragan> After looking into this discussion I think this problem is case by case basis, whichever solution fits to such problems, should be used to fix it and cannot be generalized.
17:12:14 <nirik> also, if it didn't keep track of versions it would be bad for users choice...
17:13:14 <Pharaoh_Atem> a metapkg-obsolete package could be useful for ultimate removals, but may not be quite so necessary given dnf's distro-sync capability
17:13:30 <Pharaoh_Atem> if we were still primarily using yum or supporting it, I would say that metapkg-obsolete is the right choice
17:13:58 <jwb> i'm against the metapackage, sorry
17:13:59 <nirik> distro-sync doesn't solve the problem tho. ;)
17:14:06 <nirik> and yum also had that.
17:14:36 <jwb> it's because you're trying to solve a void.  you can't do that without choice.
17:14:39 <dgilmore> do we have something to propose
17:14:46 <dgilmore> or should we just think about it more?
17:15:24 * jsmith has to go, sorry...
17:15:28 <jwb> Proposal: This is an intractable problem that has no common solution.  Handle on a case by case basis.
17:15:34 <dgilmore> +1
17:15:37 <maxamillion> +1
17:15:39 <paragan> +1
17:15:42 <Rathann> +1
17:16:43 <nirik> +1
17:16:54 <sgallagh> +1, I guess
17:17:10 <sgallagh> (Though I don't necessarily believe that it is "intractable"
17:17:32 <dgilmore> #accepted This is an intractable problem that has no common solution.  Handle on a case by case basis. (6:+ 0:- 0:0)
17:17:40 <jwb> in·trac·ta·ble
17:17:40 <jwb> ˌinˈtraktəb(ə)l/
17:17:41 <jwb> adjective
17:17:41 <jwb> hard to control or deal with.
17:17:41 <jwb> "intractable economic problems"
17:17:41 <jwb> synonyms:	unmanageable, uncontrollable, difficult, awkward, troublesome, demanding, burdensome
17:17:41 <jwb> "intractable problems"
17:18:11 <dgilmore> #topic Next week's chair
17:18:16 <dgilmore> jwb: :D
17:18:18 <nirik> is there something we can/should do about dnf-langpacks now?
17:18:39 <dgilmore> nirik: I think dnf itself should obsolete it
17:18:46 <Rathann> making dnf obsolete them was proposed
17:18:52 <dgilmore> its removed the functionality
17:19:03 <dgilmore> #undo
17:19:03 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x32099690>
17:19:13 <nirik> sounds reasonable to me. is there a bug or ?
17:19:43 <paragan> one thing I want to ask here
17:19:54 <paragan> should we add obsoletes versioned?
17:20:06 <paragan> I proposed it in dnf.spec as
17:20:09 <dgilmore> paragan: yes, but no provides
17:20:12 <paragan> Obsoletes: dnf-langpacks
17:20:36 <paragan> okay I will ask dnf developers to add version there
17:20:43 <dgilmore> Obsoletes: dnf-langpacks <= <last version shipped>
17:20:57 <paragan> dgilmore, thanks
17:21:03 <dgilmore> that allows it to come back with little pain
17:21:12 <nirik> yeah
17:21:16 <nirik> versions are best
17:21:41 <paragan> sure will get it updated in upstream dnf.spec
17:21:51 <dgilmore> paragan: cheers
17:21:53 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=1366793
17:22:55 <dgilmore> okay
17:22:59 <dgilmore> we done?
17:23:03 * nirik nods
17:23:07 <paragan> yes
17:23:31 <dgilmore> #topic Next week's chair
17:23:45 <dgilmore> who wants to do next week?
17:24:18 <Rathann> I can do it next week
17:24:55 <dgilmore> #action Rathann to run next weeks meeting
17:24:59 <dgilmore> thanks Rathann
17:25:12 <dgilmore> #topic Open Floor
17:25:55 <dgilmore> i will give a few minutes the wrap up
17:27:11 <dgilmore> #endmeeting