18:00:41 <mitr> #startmeeting FESCO (2015-04-01)
18:00:41 <zodbot> Meeting started Wed Apr  1 18:00:41 2015 UTC.  The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:44 <mitr> #meetingname fesco
18:00:44 <zodbot> The meeting name has been set to 'fesco'
18:00:46 <mitr> #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh
18:00:46 <zodbot> Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza
18:00:48 <mitr> #topic init process
18:00:50 <mitr> Hello everyone
18:00:52 <nirik> morning
18:00:55 <sgallagh> .hello sgallagh
18:00:58 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:01:01 <paragan> Hi all
18:01:13 <jwb> hello
18:01:21 <rishi> hello
18:01:25 <ajax> hi
18:02:19 * jreznik is around
18:03:23 <dgilmore> hola
18:03:23 <mitr> #topic #1384 F23 System Wide Change: Harden All Packages - https://fedoraproject.org/wiki/Changes/Harden_All_Packages
18:03:26 <mitr> .fesco 1384
18:03:28 <zodbot> mitr: #1384 (F23 System Wide Change: Harden All Packages - https://fedoraproject.org/wiki/Changes/Harden_All_Packages) – FESCo - https://fedorahosted.org/fesco/ticket/1384
18:04:15 <nirik> I think we were hoping to get more data here... but I don't know if anyone had time to gather any
18:04:28 <ajax> i dug a bit
18:05:00 <ajax> the number of packages explicitly disabling -z now at this point is pretty small
18:05:30 <ajax> or rather, explicitly disabling _hardened_build
18:05:31 <rishi> I was also waiting for ajax to clarify mitr 's question about slowdown == ABI breakage.
18:05:49 <ajax> rishi: "breakage" isn't really the word i should have used
18:06:54 <ajax> more breaking developer expectations than program functionality
18:06:55 <mitr> Yeah, that was resolved last week.
18:06:56 <rishi> ajax: Yeah, I know, but I was still curious if you had anything other than slowness in mind.
18:07:14 <rishi> mitr: Ah, ok. Sorry for interrupting then.
18:07:25 * rishi was semi-absent last week
18:07:35 <dgilmore> ajax: are the ones disabling _hardened_build because of -z? or is taht not known?
18:08:13 <ajax> dgilmore: mostly it's ada packages (for reasons discussed in the ticket) and xorg drivers
18:08:21 <dgilmore> ajax: okay
18:08:23 <mitr> I am kind of curious to know why it is being disabled by anyone at all as well, but I don’t have any direct use of that data ☺
18:08:40 <ajax> that said:
18:08:41 <ajax> hyoscyamine:/vol1/rawhide/root% file -b -e elf */usr/bin/* | grep ELF | sed 's/set.*id //' | cut -f1 -d\( | sort | uniq -c | sort -n
18:08:44 <ajax> 1 sticky ELF 64-bit LSB executable, x86-64, version 1
18:08:46 <ajax> 4453 ELF 64-bit LSB shared object, x86-64, version 1
18:08:49 <ajax> 10377 ELF 64-bit LSB executable, x86-64, version 1
18:08:59 <ajax> we haven't actually rebuilt all the executables in the world yet
18:09:12 * nirik nods.
18:09:34 <mitr> Is it fair to say that 1) the current approach and defaults are considered broadly appropriate 2) X modules have a way to opt out 3) work is slowly being done for Ada?
18:09:59 <ajax> mitr: i think so.  i've got some other numbers that are interesting in terms of measuring the performance impact
18:10:43 <ajax> and i think it'll probably be acceptably small, and that there's obvious fixes for the most impacted areas
18:10:55 <mitr> With 123 above it seems to me that we have nothing to really discuss on this meeting, and we should just drop the meeting keyword and work in the ticket.
18:11:15 <mitr> Or are the performance numbers interesting, either to overturn 1) or to raise new action items?
18:11:29 <ajax> i don't think they're interesting enough to bother with here, no
18:11:43 <mitr> (I don
18:11:53 <ajax> i'm happy to drop it from the meeting, yeah
18:11:59 <dgilmore> +1 to mitr
18:12:10 <mitr> ’t want to rush or avoid this ticket, just looking for next steps to actually do here)
18:12:14 <nirik> yep. sounds great. Thanks for digging some on it ajax
18:12:33 <ajax> i'll update the macros soon to at least fix the ld -r issue, which has caused at least one build failure
18:12:44 <ajax> and otherwise continue to work this in the ticket
18:12:45 <dgilmore> hopefully we should soon have a rawhide mass rebuild
18:13:26 <nirik> yeah... of course that won't help the c++ stuff, but oh well.
18:15:03 <mitr> So, to make it formal:
18:15:06 <mitr> Proposal: Drop meeting keyword, continue tracking work in the ticket
18:15:14 <ajax> +1
18:15:15 <mitr> (and, ajax, thanks for actually doing the research and working on patches)
18:15:21 <ajax> np
18:15:22 <rishi> +1
18:15:24 <jwb> +1
18:15:27 <nirik> +1
18:15:27 <paragan> +1
18:15:30 <rishi> Yeah, thanks ajax
18:15:46 <mitr> +1 for the record
18:15:49 <mitr> #agreed Drop meeting keyword, continue tracking work in the ticket (+6)
18:15:56 <mitr> #topic #1416 F22 Changes - Progress at Change Checkpoint: Change Checkpoint: 100% Code Complete Deadline
18:15:58 <mitr> .fesco 1416
18:16:00 <zodbot> mitr: #1416 (F22 Changes - Progress at Change Checkpoint: Change Checkpoint: 100% Code Complete Deadline) – FESCo - https://fedorahosted.org/fesco/ticket/1416
18:16:22 <mitr> https://fedorahosted.org/fesco/ticket/1416#comment:12 in particular
18:16:53 <jreznik> there's not much, this time we are looking pretty good
18:16:55 <sgallagh> So what is the question here?
18:17:09 <sgallagh> "Ask Atomic to enact its contingency plan?"
18:17:30 <mitr> Looking at contingency plans:
18:17:32 <mitr> A showstopper in rpm-ostree would block Changes/AtomicHost.  The contingency plan would be to not ship that product.
18:17:35 <mitr> If something fails and this product can't ship, some upgrade mechanism for Fedora 21 Atomic Cloud Image users would need to be evaluated. The simplest fallback is to tell those users to reinstall with a traditional Fedora 22 Cloud image.
18:18:01 <sgallagh> Not... optimal.
18:18:13 <dgilmore> I am still working to enable what I can of Atomic Host
18:18:26 <mitr> Am I reading this correctly that we would not have any Atomic deliverable in F22, and steer everyone towards F22 Cloud, or is this only saying that there won’t be an upgrade path from F21 Atomic Cloud to F22 Atomic Cloud?
18:18:27 <jwb> i'd prefer to let walters and rel-eng continue for now
18:18:28 <nirik> what is still pending?
18:18:41 <dgilmore> big issue is that they did not talk to releng until after Alpha Change freeze wanting new deliverables added
18:18:53 <jreznik> jwb: yep
18:18:55 <jwb> i think doing anything at the moment is going to cause more harm than good.  so let them work on it.
18:19:04 <dgilmore> nirik: the install media and pxe to live
18:19:25 <jwb> dgilmore, i'm slightly confused.  we reviewed the Change before freeze, right?
18:19:45 <nirik> dgilmore: ok, and you think you can get those into beta? or ?
18:19:56 <dgilmore> jwb: for alpha no
18:20:15 <jwb> hm.  i could have sworn we did.  because it came up like 3 weeks in a row
18:20:17 <dgilmore> jwb: we spent a lot of time trying to figure out what was actually proposed because it was not at all clear
18:20:53 <dgilmore> jwb: it was after change freeze that we actually figured out what they were actually proposing5
18:20:57 <mitr> jwb: Both were approved 6 days before Alpha Freeze, the AtomicHost one “tentatively” with the Change page to be clarified.
18:21:57 <mitr> Are there QA concerns about not having Atomic Host / rpmostree available for testing now?
18:22:19 <rishi> dgilmore: Since you are on the hook for the rel-eng work, do you think this can be pulled off for the Beta?
18:22:19 <dgilmore> mitr: we have a rpmostree available and have since day 1
18:22:31 <dgilmore> rishi: before beta maybe
18:22:53 <nirik> it's just those 2 images we don't have yet. :)
18:23:14 * nirik is fine with letting releng and atomic folks try and get those over the next week
18:23:48 <ajax> same
18:23:58 <mitr> same
18:24:46 <sgallagh> Shall we assert that if there's no sign of imminent fix that we enact the contingency next week?
18:24:54 <jwb> no
18:24:54 <sgallagh> Or leave that decision until then?
18:25:05 <nirik> lets revisit next week.
18:25:08 <sgallagh> ok
18:25:12 <jwb> i'd prefer to leave it until either party says it simply isn't going to happen
18:25:18 <jwb> just let them come back to us
18:25:25 <jwb> babysitting isn't going to help get it done
18:25:32 <mitr> This is a no-slip release, remember?
18:25:38 <jwb> so?
18:25:59 <sgallagh> This is blocking Beta...
18:26:29 <rishi> "lets revisit next week" doesn't necessarily conflict with "no babysitting"
18:26:39 <mitr> Without QA saying that they are fine with receiving testable deliverables that late, I would prefer enacting the contingency.
18:26:56 <jwb> when did atomic become beta blocking?
18:26:58 * rishi looks at adamw
18:27:04 <jwb> i've somehow missed that
18:27:15 <mitr> Or, at the very least, dropping this from the advertised Change list.  We should not be advertising a Change that couldn’t be sufficiently tested.
18:27:34 <sgallagh> jwb: Correct me if I'm wrong, but it's the primary output of Cloud nowadays, isn't it?
18:27:41 <jwb> incorrect afaik
18:27:41 <nirik> sgallagh: you are wrong.
18:27:44 <mitr> jwb: Changes are not necessarily beta blocking but we also don'
18:27:51 <mitr> t want risky changes post-beta.
18:27:52 <nirik> we are talking about 2 new images for atomic stuff.
18:28:11 <nirik> a installer image, ie iso that you can put on a media and boot from and install via anaconda an atomic image.
18:28:23 <nirik> and a pxe-iso thing that you can do the same thing via pxe
18:28:24 <jwb> mitr, yes, i'd prefer we just drop the Change from the list if rel-eng and the atomic people think they can accomplish this for f22 final.  i don't see this as beta blocker at all
18:28:35 <nirik> these are new this release and are not the same as the atomic cloud image
18:28:35 <sgallagh> As long as we agree that issues producing this aren't beta-blocking, then let them work however they will.
18:28:50 <roshi> afaik, Atomic is not blocking at all
18:28:51 <sgallagh> It's fundamentally a Spin at that point (though not from rel-eng perspective)
18:28:55 <jwb> nirik is all very correct
18:29:04 <roshi> there was discussion about perhaps making it so in the future - but not now
18:29:06 <nirik> sometimes. ;)
18:29:22 <mitr> nirik: So what are the Contingency Plan references to Atomic Cloud saying, then?
18:29:49 <nirik> AtomicHost you mean?
18:29:54 <nirik> Atomic Cloud was a f21 change.
18:29:56 <mitr> No, https://fedoraproject.org/wiki/Changes/AtomicHost is referring to F21 Atomic Cloud
18:30:20 <nirik> ok, that I do not know.
18:30:34 <mitr> The current plans calls for “upgrade mechanism to be evaluated”.  I honestly don’t know what that means but whatever it means it probably should happen soon
18:30:41 <dgilmore> mitr: if we do not get the two new deliverables sorted we do nothing
18:30:48 * jreznik is back, sorry I distracted by phone call
18:30:52 <jwb> you guys are kind of proving my point here.  the rel-eng and atomic people know what they're working on.  i don't think any of it is blocker.  just let them work...
18:30:57 <dgilmore> what we have works this is just additional deliverables
18:31:04 <nirik> I can't see how this change has any interaction with atomic cloud images aside from using same/similar tools to make and update them
18:31:27 <dgilmore> the atomic cloud images exist and work and are there and have been since f21
18:31:48 * nirik is +1 for revisiting next week and will shut up now. ;)
18:32:03 <sgallagh> I don't care what happens as long as it's not blocking Beta :)
18:32:26 <mitr> Proposal:
18:32:28 <mitr> 1) Ask Change owners to revisit the contingency plans and clarify
18:32:30 <mitr> 2) Don’t enact contingency plans today
18:32:32 <mitr> 3) Until QA says otherwise, hard deadline next week for deciding whether these Changes get into the advertised set.
18:32:38 <jwb> -1
18:32:40 <mitr> s/Until/Unless/
18:33:15 <mitr> jwb: How is any of this incompatible with “just let them work”?  Or what is your objection?
18:33:19 <sgallagh> mitr: +1 I think that's reasonable.
18:33:24 <jwb> there's absolutely no reason for item 3
18:33:42 <rishi> (3) is just about dropping from advertised set
18:33:46 <jwb> and?
18:33:49 <sgallagh> jwb: Websites and Marketing need time to process things too
18:34:05 <jwb> so when it gets completed in time we can scramble to add it back?
18:34:11 <jwb> next week is entirely arbitrary
18:34:12 <rishi> jwb: It isn't saying that we invoke the contingency plan, if that is your concern.
18:34:17 <mitr> jwb: There needs to be _some_ deadline before GA, and that deadline is, per schedule, yesterday.
18:34:37 <jwb> yes, let's trip over process for something that will work itself out
18:34:46 <mitr> Yes, next week is arbitrary; if we don’t want arbitrary then drop it today.
18:34:49 <jwb> look, you can all vote however you want.  i vote -1
18:35:11 <nirik> why not just change 3 to 'revisit next week'
18:35:22 <nirik> would that satisfy everyone?
18:35:31 <ajax> +1 either way honestly
18:35:45 <jwb> nirik, consensus is not required :)
18:35:51 <mitr> but nice :)
18:35:53 <sgallagh> jwb: But desired
18:35:57 <nirik> sure, but it's nice.
18:36:06 <mitr> We can revoke the hard deadline next week anyway…
18:36:32 <mitr> OK, 3a: Revisit next week, invite QA for an opinion on hard deadline.
18:36:43 <nirik> sure, +1
18:36:51 <paragan> mitr, +1
18:37:07 <dgilmore> +1
18:37:34 <rishi> +1 (if dgilmore says +1 and he is on the hook, so ...)
18:37:45 <rishi> (and it looks reasonable to me anyway)
18:37:49 <jwb> +1
18:38:00 <jwb> though i miss contentious votes
18:38:15 <nirik> jwb: troublemaker!
18:38:16 <mitr> #agreed 1) Ask Change owners to revisit the contingency plans and clarify
18:38:18 <mitr> 2) Don’t enact contingency plans today
18:38:21 <mitr> 3) Revisit next week, invite QA for an opinion on hard deadline
18:38:23 <mitr> (+8)
18:38:25 <mitr> #topic #1424 Clarifications to Change policy for changes which require rel-eng changes
18:38:27 <mitr> .fesco 1424
18:38:29 <zodbot> mitr: #1424 (Clarifications to Change policy for changes which require rel-eng changes) – FESCo - https://fedorahosted.org/fesco/ticket/1424
18:39:11 <rishi> Looked reasonable to me from the outset.
18:39:15 <dgilmore> i am +1 for this
18:39:28 <rishi> +1
18:39:36 <nirik> sure, seems fine. +1
18:39:37 <dgilmore> it would have avoided a lot of issues with the AtomicHost change
18:39:39 <mitr> +1
18:40:03 <ajax> +1
18:40:06 <jwb> +1
18:40:26 * jreznik can adjust policy process, sounds reasonable
18:40:33 <paragan> yes looks good +1
18:40:34 <sgallagh> +1
18:40:46 <mitr> #agreed Clarifications approved (+7)
18:40:48 <mitr> #action jreznik will update policy process
18:40:57 <jreznik> I'd say file a ticket before change is approved - to get more feedback from rel-eng prior approval
18:41:30 <jwb> implementation detail.  i'd leave that up to the Change process guy jreznik ;)
18:41:41 <dgilmore> jreznik: well they should talk to releng when putting the change together, that way releng can let them know what and how things need to be done
18:42:00 <mitr> I don’t think we really need a verifiable audit trail that rel-eng has been contacted and to have a process for verifying all of this; we will know by Alpha Freeze.
18:42:06 <dgilmore> jreznik: does not have to be a ticket but could be
18:42:46 <mitr> #topic #1426 Update freeze dates in the schedule
18:42:48 <mitr> .fesco 1426
18:42:49 <zodbot> mitr: #1426 (Update freeze dates in the schedule) – FESCo - https://fedorahosted.org/fesco/ticket/1426
18:43:15 <nirik> IMHO this isn't date, it's time. ;) Just update the schedule to note the cutoff is 00:00UTC tuesday
18:43:27 <sgallagh> What are we discussing here? I thought this was just a clarification of how things actually work.
18:43:27 <dgilmore> the only added thing is a clarification and a concrete time you have to have changes pending for stable in bodhi
18:43:34 <dgilmore> sgallagh: it is
18:43:42 <sgallagh> /me nods
18:43:48 <nirik> right. It's often been a point of confusion...
18:44:06 <nirik> saying that you have to have your package submitted for stable by 00:00UTC clears things up.
18:44:51 <mitr> So, no controversy (sorry, jwb), and jreznik, please say 0:0 UTC somewhere in the schedule?
18:44:52 <dgilmore> right, the time will go for Alpha and Final
18:45:10 <jwb> heh
18:45:20 <nirik> and Beta! :)
18:45:23 <dgilmore> the freeze will be enforced shortly after 00:00UTC on the freeze day
18:45:27 <jreznik> mitr: consider ti done
18:45:32 <jreznik> it
18:45:38 <dgilmore> nirik: well in adition to Beta
18:45:42 <nirik> right
18:45:44 <mitr> #action jreznik to clarify that packages need to be in bodhi at 0:00 UTC on the freeze date
18:45:54 <dgilmore> since this came up for the Beta Freeze
18:45:54 <mitr> #topic Next week's chair
18:45:58 <jreznik> dgilmore: btw. I'm not sure freeze was announced this time
18:46:11 <dgilmore> jreznik: possible :(
18:46:16 <jwb> i will be absent next week.
18:46:33 <mitr> I will very likely be absent next week as well.
18:46:37 <mitr> Anyone to chair next week?
18:46:43 <dgilmore> I will have my daughter home all next week. so I will be somewhat absent
18:46:44 <jreznik> dgilmore: could you send it pls?
18:46:48 <dgilmore> jreznik: sure
18:46:55 <jreznik> thx
18:47:12 <jreznik> I'd announced the time thing there too
18:47:44 * nirik guesses he could do it next week.
18:47:50 <mitr> Thanks!
18:47:57 <mitr> #info nirik will chair next week’s meeting
18:48:03 <mitr> #topic Open Floor
18:48:10 <mitr> Any other topics to discuss today?
18:48:16 <nirik> do we want to revisit the dnf-yum thing?
18:48:23 <nirik> adamw had some strong concerns...
18:48:30 <paragan> I am thinking the same to discuss here
18:48:32 <nirik> and it seems people didn't realize what it meant.
18:48:38 <nirik> or that anything changed.
18:48:54 <paragan> I think what we approved plan is implemented now
18:49:10 <nirik> well, barring some broken packages... new fixed ones need to go to stable.
18:49:20 <paragan> right
18:49:28 <mitr> Unfortunately our Requires: yum doesn't say whether it requries /usr/bin/yum or the python modules, so we don’t have data.
18:50:05 <nirik> yep.
18:50:55 <jwb> i'm still not for the approved plan at all
18:51:12 <mitr> Overall, if the tradeoff is “have systems where /usr/bin/yum doesn’t exist, and no way to fix it in F22” vs. “have some not-perfectly-maintained tools broken, with a simple sed and a dependency change fixing them at any time in F22”, I'd rather have the latter.
18:51:50 <mitr> Perhaps we should make a devel announcement about this happening, because it has been IIRC very silent and people may not be aware.
18:52:09 <nirik> hurray. another long devel thread.
18:52:11 <mitr> Finding a volunteer to go through all packages that Require:yum and check whether they need updating would be awesome.
18:52:14 <nirik> but sure
18:52:27 <ajax> there's only like 60 such in f21
18:52:28 <nirik> I think there's already a tracker bug for that?
18:52:39 <ajax> i'd know for f23 if dnf would hurry up
18:52:45 <ajax> 35!
18:52:48 <paragan> nirik, yes to migrate from yum to dnf
18:53:29 <mitr> That tracker is https://bugzilla.redhat.com/show_bug.cgi?id=1156491
18:53:30 <nirik> https://bugzilla.redhat.com/showdependencytree.cgi?id=1156491&hide_resolved=1
18:53:33 <nirik> yeah
18:54:15 <mitr> Or, instead of a devel thread, mass-comment on the bugs blocking this?
18:54:39 <paragan> I can volunteer for this dnf-yum work
18:54:46 <nirik> I think a devel note is still good too
18:54:54 <adamw> mitr: what exactly is the problem with systems not having /usr/bin/yum ?
18:55:03 <mitr> adamw: documentation all over the internet
18:55:15 <drago01> just put a symlink
18:55:23 <drago01> most commands would work just fine
18:55:24 <nirik> we have already seen the cloud image bugs starting in from alpha
18:55:30 <nirik> drago01: that is dnf-yum.
18:55:30 <adamw> and why is 'a file not being there' a worse problem than 'we have two rather different things providing the same file, that don't behave the same or even have a formally agreed-upon and widely known subset of common behaviour'?
18:55:30 <mitr> drago01: That’s what the plan being discussed basically is
18:55:31 <rishi> drago01: Isn't that what we are arguing about?
18:55:50 * drago01 shuts up
18:56:06 <nirik> adamw: because 'yum install foobar' in a guide will work just fine with yum-dnf
18:56:17 <nirik> and also tell you to read up on dnf and yum differences.
18:56:19 <adamw> so will people's brains when they say 'oh yeah, they replaced yum with dnf'.
18:56:26 <mitr> adamw: I thought the subset of common behavior is formally defined by the complement of http://dnf.readthedocs.org/en/latest/cli_vs_yum.html
18:56:27 <drago01> (I though it was about having a "real" yum)
18:56:28 <rishi> I, personally, switched to dnf few months ago and haven't noticed any difference.
18:56:52 <adamw> mitr: that's after-the-fact documentation, not a previously-arranged plan.
18:56:55 <nirik> adamw: for those people who follow... for many it will be 'they replaced yum with... what? huh? how do I install yum!'
18:56:58 <rishi> But then, maybe my use-case is very simple and doesn't hit the cracks.
18:57:06 <drago01> is there any reason why we can't just drop the "real" yum (i.e the command not the libs) ?
18:57:07 <adamw> nirik: i really don't think people are that dumb. i just don't.
18:57:10 <mitr> adamw: How would users who only install GA releases tell the difference?
18:57:15 <adamw> we've changed things before and no-one died.
18:57:17 <paragan> I used new packages today and yum commands are working fine as they are redirecting to dnf
18:57:21 <mitr> drago01: Lack of work being finished to port dependencies
18:57:33 <nirik> adamw: I don't think it's dumbness... it's just not caring to follow random things in fedora... they just want to do things with it.
18:57:37 <drago01> mitr: like?
18:57:46 <drago01> mitr: I said keep the api remove the command
18:57:50 <adamw> nirik: you really don't think the meme 'oh yeah, they replaced yum with dnf' will get out there?
18:57:54 <ajax> hah, we still package mach
18:57:54 <nirik> drago01: we are.
18:57:58 <mitr> drago01: We don’t actually precisely know because the deps don’t track this
18:58:04 <adamw> i mean, we used to use up2date, remember?
18:58:09 <jwb> and pirut!
18:58:09 <nirik> no. ;)
18:58:15 <adamw> EXACTLY
18:58:20 <nirik> I have drunk those memories away.
18:58:29 <jwb> look, the internet still talks about stuff from RHL9
18:58:32 <adamw> we didn't come up with a half-cocked plan to symlink those names. we just gave people the new thing and said, here's the new thing.
18:59:10 <nirik> well, those things were not that similar to what replaced them
18:59:12 <jwb> imagine a world where we've built up the rings idea into atomic baseOS+DE/Server layers
18:59:13 <rishi> adamw: Well, the new thing isn't that new for quite some people.
18:59:14 <adamw> anyhow, i probably said enough, i'm with jwb, dnf-yum is a bad idea and we shouldn't do it. i'll shut up now.
18:59:36 <jwb> do you think we're going to wrap 'atomic host upgrade' with yum too?
18:59:37 <rishi> adamw: For the simple install, update case you can trivially replace yum with dnf.
18:59:42 <jwb> why isn't this a concern there?
19:00:01 <rishi> jwb: Because atomic isn't about packages?
19:00:12 <nirik> I think it's better than it was before and acceptable now... but perhaps we will find out more with beta...
19:00:33 * jwb thinks he and adamw are alone in this
19:00:40 <mitr> jwb: 1) Different approach to this overall (e.g. no ability to upgrade a single package), and 2) Users explicitly opt in by installing a different image.
19:00:45 <sgallagh> I'm coming down on adamw and jwb's side on this. It's not the same thing, though it shares some common behaviors.
19:01:01 <jwb> mitr, today, yes.  in the future, that may not be the case
19:01:23 <nirik> sgallagh: and it tells them to look at those. ;)
19:01:29 <jwb> this is very simple.  it's a change.  it's a non compatible 1:1 replacement.  it shouldn't be pretending to be something it isn't.
19:01:36 <adamw> oh, just for the record, we haven't had a formal QA discussion on this, my opinions are my own, not 'QA's'.
19:01:37 <rishi> jwb: What might not be the case tomorrow? (1) or (2) ?
19:01:45 <sgallagh> I'd somewhat rather we just put the nag comment on the real yum and just washed our hands of it
19:01:48 <roshi> FWIW, I'm also for just making the swap and being done with it
19:01:49 <mitr> jwb: I’m not sure I want this to become a very general philosophical discussion about the tradeoff in saving users’ friction vs. developers’ work.
19:02:03 <jwb> rishi, that's a tangent that probably isn't going to help this conversation so i'll just let it go
19:02:17 <nirik> anyhow, I guess I can make the devel list post and everyone can flame on there.
19:02:54 <sgallagh> nirik: We're in Freeze. Do we really want to wait to wade through a flamewar before deciding on this?
19:03:00 <mitr> If we are freezing Beta with this, would we still consider reverting?
19:03:02 <nirik> sgallagh: we already decided this.
19:03:09 <nirik> unless someone is putting out a new proposal
19:03:16 <sgallagh> nirik: I wasn't around that day. And yes, I am.
19:03:24 <nirik> ok
19:03:40 <mitr> sgallagh: We need to get the word out that dependencies need to be slightly edited if they haven't been completely ported anyway, flamewar or not.
19:03:40 <adamw> you decided it twice, didn't you?
19:03:40 <sgallagh> Proposal: Do not ship with dnf-yum by default. Modify the real yum binary with a warning that this command is deprecated in favor of DNF.
19:03:46 <nirik> adamw: at least
19:04:13 <nirik> sgallagh: clarification... what is 'the real yum binary' ?
19:04:16 <jwb> adamw, we did.  in different ways.
19:04:20 <paragan> we have already decided yum to dnf migration plan, approved it, set deadline to developers and now we don't want that implementation?
19:04:20 <adamw> first everyone voted to *not* do dnf-yum, then mattdm said he'd like to do it, and you all changed your minds and decided to do it. oh, but before that, the Change was approved saying dnf-yum would be part of it, so I guess so far the meta-decision is 2-1 in favour of doing it. :P
19:04:22 <mitr> sgallagh: … and ship yum in the minimal install?  Or leave /usr/bin/yum missing?
19:04:24 <drago01> how about this again (somehow got lost) "DROP the real yum binary"
19:04:26 <sgallagh> nirik: /usr/bin/yum as provided by the 'yum' package
19:04:33 <jwb> adamw, not all.
19:04:34 <drago01> replace it with a symlink to dnf or dnf-yum
19:04:35 <drago01> done
19:04:45 <adamw> jwb: sorry, was using it in the Texas sense.
19:04:47 <nirik> adamw: I was against it as it was orig setup... with dnf-yum conflicting with yum
19:05:02 <rishi> drago01: That was already proposed on the ticket.
19:05:07 <rishi> And apparently we are not happy with it.
19:05:11 <mitr> drago01: Strictly worse than all of the other alternatives, breaks software and leaves it scrambling to port to yum
19:05:29 <mitr> .. port to dnf obviously
19:05:36 <drago01> mitr: "break software" ?
19:05:39 <mattdm> adamw: when the change was improved, the question of what would be the new /usr/bin/yum was left unanswered
19:05:47 <drago01> if the software is using the yum api it should work fine
19:05:50 <drago01> its still present
19:05:54 <nirik> adamw: this is dnf-yum provides /usr/bin/yum and a message and runs dnf. yum can still be installed fine, and run with yum-deprecated and it's api is still at the same place..
19:05:59 <sgallagh> mitr: I'm inclined to let yum stay in the default install for F22 with the deprecation warning stating that it will be *removed* in F23.
19:06:30 <sgallagh> And then kill off the package entirely there.
19:06:30 <mitr> drago01: If it using the _binary_, it will not.  Now either the differences don’t matter, in which case we should IMHO just use the new thing, or the differences matter and then removing the original binary breaks sthings.
19:06:50 <jwb> sgallagh, that won't lead to dnf being the default.
19:07:11 <jwb> it will lead to people still using yum in f22 and then hitting the pain point in f23
19:07:20 <nirik> FYI, if anyone cares the '/usr/bin/yum' message is:
19:07:23 <nirik> yum list foobar
19:07:23 <nirik> Yum command has been deprecated, use dnf instead.
19:07:23 <nirik> See 'man dnf' and 'man yum2dnf' for more information.
19:07:23 <nirik> To transfer transaction metadata from yum to DNF, run 'dnf migrate'Redirecting to '/usr/bin/dnf list foobar'
19:07:23 <sgallagh> jwb: What do you mean? We nag them every time the use yum and let them know that it won't be there in the next release. How does that not make DNF the default?
19:07:35 <drago01> mitr: so the "porting" you are talking about is changes between yum and dnf command line arguments for obscure cases where they differ?
19:07:40 * rishi is totally confused now
19:07:41 <mitr> drago01: yes
19:07:46 <jwb> sgallagh, because people will ignore the nag and still type 'yum'??
19:08:26 <adamw> drago01: they really aren't that obscure. 'yum update' and 'dnf update' do different things if there is a dependency issue, for instance.
19:08:47 <adamw> 'yum update' fails and reports the error. 'dnf update' drops the packages with issues and completes and doesn't tell you there was a problem at all.
19:08:56 <adamw> this is not a *minor* behaviour difference.
19:08:58 <mattdm> also "package 'dnf-yum' is installed by default. It obsoletes Yum and provides its own /usr/bin/yum" has been in the feature description for a very long time
19:09:04 <drago01> adamw: is there any software that tries to parse the yum output?
19:09:09 <drago01> that would be beyond crazy
19:09:10 <adamw> i don't know.
19:09:15 <nirik> I'm sure there is.
19:09:19 <adamw> the point is they differ in behaviour in significant and obvious ways.
19:09:25 <drago01> ugh
19:09:29 <adamw> as jwb said, they are *not* the same thing. one should not pretend to be the other.
19:09:40 <mattdm> people with software parsing the yum output are already used to that output changing from yum version toversion.
19:09:44 <adamw> the dnf devs dropped the goal for dnf to be a precise replacement for yum in any way years ago.
19:09:47 <rishi> How about we go through the items in the blocker and find out who shells ot to yum and whether they excercise the differences with dnf? Or has that already been done?
19:10:03 <nirik> rishi: which blocker?
19:10:04 <drago01> mattdm: yeah that's not really something that ever was guaranted to be stable
19:10:10 <rishi> nirik: https://bugzilla.redhat.com/show_bug.cgi?id=1156491
19:10:24 <nirik> thats a tracker... not a blocker. ;)
19:10:35 <rishi> Sorry, terminology.
19:10:46 <drago01> http://ghantoos.org/2008/09/28/yum-output-parser/ ...
19:11:16 <rishi> "The script is quite easy to use"
19:11:26 * dgilmore needs to run and pick up daughter from School
19:11:41 <nirik> also, whoever filed those bugs didn't use the name in the subjects so it makes it really hard to tell whats what
19:11:44 <jwb> unfortunately i have a hard stop in 10min.  fortunately, i don't really have anything further to add to the conversation
19:12:04 <nirik> jwb: but at least we had some contention! :)
19:12:16 <jwb> yes!
19:12:21 <rishi> nirik: Yeah.
19:12:26 <rishi> The subjects suck.
19:13:46 <nirik> anyhow, where are we? I am -1 to sgallaghs proposal... but I suppose we could see how beta goes and revisit after? or are there enough +1s to pass it now?
19:13:58 <paragan> nirik, +1
19:14:09 <sgallagh> paragan: What are you +1ing?
19:14:32 <paragan> sgallagh, to nirik's proposal to have new dnf packages in F22 Beta
19:14:41 <rishi> Why does an exception handling library use yum: https://bugzilla.redhat.com/show_bug.cgi?id=1156483 ?
19:14:45 * rishi scratches head
19:14:51 <mitr> rishi: We are not going to analyze all of the 35 here
19:15:14 <mitr> I am -1 to reverting this again; let’s go with /usr/bin/yum taken over by yum-dnf
19:15:18 <nirik> not having /usr/bin/yum will annoy some people, having it call dnf will annoy others. I contend that the second group can more easily switch to the real yum and fix their stuff than the first group can discover that they need to re-run with 'dnf' instead of 'yum'
19:17:22 * nirik guesses we bored everyone to death. :)
19:17:55 * mitr pretends nothing is going on
19:17:59 <sgallagh> heh
19:18:02 <ajax> was something proposed?
19:18:02 <mitr> Any other topics for to discuss today?
19:18:12 <ajax> (he regrets asking)
19:18:21 <nirik> ajax: [13:03:40] <sgallagh> Proposal: Do not ship with dnf-yum by default. Modify the real yum binary with a warning that this command is deprecated in favor of DNF.
19:18:30 * rishi just goes through the list blocking https://bugzilla.redhat.com/show_bug.cgi?id=1156491
19:18:39 <sgallagh> I'm still not happy with the current state of dnf-yum, but it doesn't look like enough of you agree with me.
19:18:40 <rishi> ... that is more useful than going around in circles. :)
19:19:00 <ajax> i only recall voting on this issue once?
19:19:01 <nirik> I think we could revist after beta too... it shouldn't be difficult to change it...
19:19:08 <ajax> which i think is because it predates my term
19:19:13 <nirik> if there's some unseen well of doom.
19:19:16 <sgallagh> So I will log my displeasure and withdraw from the discussion.
19:19:18 <ajax> but i don't see a lot of point in reverting so -1 to that
19:19:36 <ajax> and i think that's even consistent with how i voted the first time!
19:20:46 <mitr> Anything else to discuss?  If not, I will close the meeting in 2 minutes
19:20:59 <ajax> nothing from me
19:21:09 * nirik has nothing
19:21:20 <rishi> Nothing.
19:22:53 <mitr> Thanks, everyone!
19:22:56 <mitr> #endmeeting