18:00:41 #startmeeting FESCO (2015-04-01) 18:00:41 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:44 #meetingname fesco 18:00:44 The meeting name has been set to 'fesco' 18:00:46 #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh 18:00:46 Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza 18:00:48 #topic init process 18:00:50 Hello everyone 18:00:52 morning 18:00:55 .hello sgallagh 18:00:58 sgallagh: sgallagh 'Stephen Gallagher' 18:01:01 Hi all 18:01:13 hello 18:01:21 hello 18:01:25 hi 18:02:19 * jreznik is around 18:03:23 hola 18:03:23 #topic #1384 F23 System Wide Change: Harden All Packages - https://fedoraproject.org/wiki/Changes/Harden_All_Packages 18:03:26 .fesco 1384 18:03:28 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 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 i dug a bit 18:05:00 the number of packages explicitly disabling -z now at this point is pretty small 18:05:30 or rather, explicitly disabling _hardened_build 18:05:31 I was also waiting for ajax to clarify mitr 's question about slowdown == ABI breakage. 18:05:49 rishi: "breakage" isn't really the word i should have used 18:06:54 more breaking developer expectations than program functionality 18:06:55 Yeah, that was resolved last week. 18:06:56 ajax: Yeah, I know, but I was still curious if you had anything other than slowness in mind. 18:07:14 mitr: Ah, ok. Sorry for interrupting then. 18:07:25 * rishi was semi-absent last week 18:07:35 ajax: are the ones disabling _hardened_build because of -z? or is taht not known? 18:08:13 dgilmore: mostly it's ada packages (for reasons discussed in the ticket) and xorg drivers 18:08:21 ajax: okay 18:08:23 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 that said: 18:08:41 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 1 sticky ELF 64-bit LSB executable, x86-64, version 1 18:08:46 4453 ELF 64-bit LSB shared object, x86-64, version 1 18:08:49 10377 ELF 64-bit LSB executable, x86-64, version 1 18:08:59 we haven't actually rebuilt all the executables in the world yet 18:09:12 * nirik nods. 18:09:34 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 mitr: i think so. i've got some other numbers that are interesting in terms of measuring the performance impact 18:10:43 and i think it'll probably be acceptably small, and that there's obvious fixes for the most impacted areas 18:10:55 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 Or are the performance numbers interesting, either to overturn 1) or to raise new action items? 18:11:29 i don't think they're interesting enough to bother with here, no 18:11:43 (I don 18:11:53 i'm happy to drop it from the meeting, yeah 18:11:59 +1 to mitr 18:12:10 ’t want to rush or avoid this ticket, just looking for next steps to actually do here) 18:12:14 yep. sounds great. Thanks for digging some on it ajax 18:12:33 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 and otherwise continue to work this in the ticket 18:12:45 hopefully we should soon have a rawhide mass rebuild 18:13:26 yeah... of course that won't help the c++ stuff, but oh well. 18:15:03 So, to make it formal: 18:15:06 Proposal: Drop meeting keyword, continue tracking work in the ticket 18:15:14 +1 18:15:15 (and, ajax, thanks for actually doing the research and working on patches) 18:15:21 np 18:15:22 +1 18:15:24 +1 18:15:27 +1 18:15:27 +1 18:15:30 Yeah, thanks ajax 18:15:46 +1 for the record 18:15:49 #agreed Drop meeting keyword, continue tracking work in the ticket (+6) 18:15:56 #topic #1416 F22 Changes - Progress at Change Checkpoint: Change Checkpoint: 100% Code Complete Deadline 18:15:58 .fesco 1416 18:16:00 mitr: #1416 (F22 Changes - Progress at Change Checkpoint: Change Checkpoint: 100% Code Complete Deadline) – FESCo - https://fedorahosted.org/fesco/ticket/1416 18:16:22 https://fedorahosted.org/fesco/ticket/1416#comment:12 in particular 18:16:53 there's not much, this time we are looking pretty good 18:16:55 So what is the question here? 18:17:09 "Ask Atomic to enact its contingency plan?" 18:17:30 Looking at contingency plans: 18:17:32 A showstopper in rpm-ostree would block Changes/AtomicHost. The contingency plan would be to not ship that product. 18:17:35 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 Not... optimal. 18:18:13 I am still working to enable what I can of Atomic Host 18:18:26 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 i'd prefer to let walters and rel-eng continue for now 18:18:28 what is still pending? 18:18:41 big issue is that they did not talk to releng until after Alpha Change freeze wanting new deliverables added 18:18:53 jwb: yep 18:18:55 i think doing anything at the moment is going to cause more harm than good. so let them work on it. 18:19:04 nirik: the install media and pxe to live 18:19:25 dgilmore, i'm slightly confused. we reviewed the Change before freeze, right? 18:19:45 dgilmore: ok, and you think you can get those into beta? or ? 18:19:56 jwb: for alpha no 18:20:15 hm. i could have sworn we did. because it came up like 3 weeks in a row 18:20:17 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 jwb: it was after change freeze that we actually figured out what they were actually proposing5 18:20:57 jwb: Both were approved 6 days before Alpha Freeze, the AtomicHost one “tentatively” with the Change page to be clarified. 18:21:57 Are there QA concerns about not having Atomic Host / rpmostree available for testing now? 18:22:19 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 mitr: we have a rpmostree available and have since day 1 18:22:31 rishi: before beta maybe 18:22:53 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 same 18:23:58 same 18:24:46 Shall we assert that if there's no sign of imminent fix that we enact the contingency next week? 18:24:54 no 18:24:54 Or leave that decision until then? 18:25:05 lets revisit next week. 18:25:08 ok 18:25:12 i'd prefer to leave it until either party says it simply isn't going to happen 18:25:18 just let them come back to us 18:25:25 babysitting isn't going to help get it done 18:25:32 This is a no-slip release, remember? 18:25:38 so? 18:25:59 This is blocking Beta... 18:26:29 "lets revisit next week" doesn't necessarily conflict with "no babysitting" 18:26:39 Without QA saying that they are fine with receiving testable deliverables that late, I would prefer enacting the contingency. 18:26:56 when did atomic become beta blocking? 18:26:58 * rishi looks at adamw 18:27:04 i've somehow missed that 18:27:15 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 jwb: Correct me if I'm wrong, but it's the primary output of Cloud nowadays, isn't it? 18:27:41 incorrect afaik 18:27:41 sgallagh: you are wrong. 18:27:44 jwb: Changes are not necessarily beta blocking but we also don' 18:27:51 t want risky changes post-beta. 18:27:52 we are talking about 2 new images for atomic stuff. 18:28:11 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 and a pxe-iso thing that you can do the same thing via pxe 18:28:24 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 these are new this release and are not the same as the atomic cloud image 18:28:35 As long as we agree that issues producing this aren't beta-blocking, then let them work however they will. 18:28:50 afaik, Atomic is not blocking at all 18:28:51 It's fundamentally a Spin at that point (though not from rel-eng perspective) 18:28:55 nirik is all very correct 18:29:04 there was discussion about perhaps making it so in the future - but not now 18:29:06 sometimes. ;) 18:29:22 nirik: So what are the Contingency Plan references to Atomic Cloud saying, then? 18:29:49 AtomicHost you mean? 18:29:54 Atomic Cloud was a f21 change. 18:29:56 No, https://fedoraproject.org/wiki/Changes/AtomicHost is referring to F21 Atomic Cloud 18:30:20 ok, that I do not know. 18:30:34 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 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 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 what we have works this is just additional deliverables 18:31:04 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 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 I don't care what happens as long as it's not blocking Beta :) 18:32:26 Proposal: 18:32:28 1) Ask Change owners to revisit the contingency plans and clarify 18:32:30 2) Don’t enact contingency plans today 18:32:32 3) Until QA says otherwise, hard deadline next week for deciding whether these Changes get into the advertised set. 18:32:38 -1 18:32:40 s/Until/Unless/ 18:33:15 jwb: How is any of this incompatible with “just let them work”? Or what is your objection? 18:33:19 mitr: +1 I think that's reasonable. 18:33:24 there's absolutely no reason for item 3 18:33:42 (3) is just about dropping from advertised set 18:33:46 and? 18:33:49 jwb: Websites and Marketing need time to process things too 18:34:05 so when it gets completed in time we can scramble to add it back? 18:34:11 next week is entirely arbitrary 18:34:12 jwb: It isn't saying that we invoke the contingency plan, if that is your concern. 18:34:17 jwb: There needs to be _some_ deadline before GA, and that deadline is, per schedule, yesterday. 18:34:37 yes, let's trip over process for something that will work itself out 18:34:46 Yes, next week is arbitrary; if we don’t want arbitrary then drop it today. 18:34:49 look, you can all vote however you want. i vote -1 18:35:11 why not just change 3 to 'revisit next week' 18:35:22 would that satisfy everyone? 18:35:31 +1 either way honestly 18:35:45 nirik, consensus is not required :) 18:35:51 but nice :) 18:35:53 jwb: But desired 18:35:57 sure, but it's nice. 18:36:06 We can revoke the hard deadline next week anyway… 18:36:32 OK, 3a: Revisit next week, invite QA for an opinion on hard deadline. 18:36:43 sure, +1 18:36:51 mitr, +1 18:37:07 +1 18:37:34 +1 (if dgilmore says +1 and he is on the hook, so ...) 18:37:45 (and it looks reasonable to me anyway) 18:37:49 +1 18:38:00 though i miss contentious votes 18:38:15 jwb: troublemaker! 18:38:16 #agreed 1) Ask Change owners to revisit the contingency plans and clarify 18:38:18 2) Don’t enact contingency plans today 18:38:21 3) Revisit next week, invite QA for an opinion on hard deadline 18:38:23 (+8) 18:38:25 #topic #1424 Clarifications to Change policy for changes which require rel-eng changes 18:38:27 .fesco 1424 18:38:29 mitr: #1424 (Clarifications to Change policy for changes which require rel-eng changes) – FESCo - https://fedorahosted.org/fesco/ticket/1424 18:39:11 Looked reasonable to me from the outset. 18:39:15 i am +1 for this 18:39:28 +1 18:39:36 sure, seems fine. +1 18:39:37 it would have avoided a lot of issues with the AtomicHost change 18:39:39 +1 18:40:03 +1 18:40:06 +1 18:40:26 * jreznik can adjust policy process, sounds reasonable 18:40:33 yes looks good +1 18:40:34 +1 18:40:46 #agreed Clarifications approved (+7) 18:40:48 #action jreznik will update policy process 18:40:57 I'd say file a ticket before change is approved - to get more feedback from rel-eng prior approval 18:41:30 implementation detail. i'd leave that up to the Change process guy jreznik ;) 18:41:41 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 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 jreznik: does not have to be a ticket but could be 18:42:46 #topic #1426 Update freeze dates in the schedule 18:42:48 .fesco 1426 18:42:49 mitr: #1426 (Update freeze dates in the schedule) – FESCo - https://fedorahosted.org/fesco/ticket/1426 18:43:15 IMHO this isn't date, it's time. ;) Just update the schedule to note the cutoff is 00:00UTC tuesday 18:43:27 What are we discussing here? I thought this was just a clarification of how things actually work. 18:43:27 the only added thing is a clarification and a concrete time you have to have changes pending for stable in bodhi 18:43:34 sgallagh: it is 18:43:42 /me nods 18:43:48 right. It's often been a point of confusion... 18:44:06 saying that you have to have your package submitted for stable by 00:00UTC clears things up. 18:44:51 So, no controversy (sorry, jwb), and jreznik, please say 0:0 UTC somewhere in the schedule? 18:44:52 right, the time will go for Alpha and Final 18:45:10 heh 18:45:20 and Beta! :) 18:45:23 the freeze will be enforced shortly after 00:00UTC on the freeze day 18:45:27 mitr: consider ti done 18:45:32 it 18:45:38 nirik: well in adition to Beta 18:45:42 right 18:45:44 #action jreznik to clarify that packages need to be in bodhi at 0:00 UTC on the freeze date 18:45:54 since this came up for the Beta Freeze 18:45:54 #topic Next week's chair 18:45:58 dgilmore: btw. I'm not sure freeze was announced this time 18:46:11 jreznik: possible :( 18:46:16 i will be absent next week. 18:46:33 I will very likely be absent next week as well. 18:46:37 Anyone to chair next week? 18:46:43 I will have my daughter home all next week. so I will be somewhat absent 18:46:44 dgilmore: could you send it pls? 18:46:48 jreznik: sure 18:46:55 thx 18:47:12 I'd announced the time thing there too 18:47:44 * nirik guesses he could do it next week. 18:47:50 Thanks! 18:47:57 #info nirik will chair next week’s meeting 18:48:03 #topic Open Floor 18:48:10 Any other topics to discuss today? 18:48:16 do we want to revisit the dnf-yum thing? 18:48:23 adamw had some strong concerns... 18:48:30 I am thinking the same to discuss here 18:48:32 and it seems people didn't realize what it meant. 18:48:38 or that anything changed. 18:48:54 I think what we approved plan is implemented now 18:49:10 well, barring some broken packages... new fixed ones need to go to stable. 18:49:20 right 18:49:28 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 yep. 18:50:55 i'm still not for the approved plan at all 18:51:12 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 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 hurray. another long devel thread. 18:52:11 Finding a volunteer to go through all packages that Require:yum and check whether they need updating would be awesome. 18:52:14 but sure 18:52:27 there's only like 60 such in f21 18:52:28 I think there's already a tracker bug for that? 18:52:39 i'd know for f23 if dnf would hurry up 18:52:45 35! 18:52:48 nirik, yes to migrate from yum to dnf 18:53:29 That tracker is https://bugzilla.redhat.com/show_bug.cgi?id=1156491 18:53:30 https://bugzilla.redhat.com/showdependencytree.cgi?id=1156491&hide_resolved=1 18:53:33 yeah 18:54:15 Or, instead of a devel thread, mass-comment on the bugs blocking this? 18:54:39 I can volunteer for this dnf-yum work 18:54:46 I think a devel note is still good too 18:54:54 mitr: what exactly is the problem with systems not having /usr/bin/yum ? 18:55:03 adamw: documentation all over the internet 18:55:15 just put a symlink 18:55:23 most commands would work just fine 18:55:24 we have already seen the cloud image bugs starting in from alpha 18:55:30 drago01: that is dnf-yum. 18:55:30 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 drago01: That’s what the plan being discussed basically is 18:55:31 drago01: Isn't that what we are arguing about? 18:55:50 * drago01 shuts up 18:56:06 adamw: because 'yum install foobar' in a guide will work just fine with yum-dnf 18:56:17 and also tell you to read up on dnf and yum differences. 18:56:19 so will people's brains when they say 'oh yeah, they replaced yum with dnf'. 18:56:26 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 (I though it was about having a "real" yum) 18:56:28 I, personally, switched to dnf few months ago and haven't noticed any difference. 18:56:52 mitr: that's after-the-fact documentation, not a previously-arranged plan. 18:56:55 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 But then, maybe my use-case is very simple and doesn't hit the cracks. 18:57:06 is there any reason why we can't just drop the "real" yum (i.e the command not the libs) ? 18:57:07 nirik: i really don't think people are that dumb. i just don't. 18:57:10 adamw: How would users who only install GA releases tell the difference? 18:57:15 we've changed things before and no-one died. 18:57:17 I used new packages today and yum commands are working fine as they are redirecting to dnf 18:57:21 drago01: Lack of work being finished to port dependencies 18:57:33 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 mitr: like? 18:57:46 mitr: I said keep the api remove the command 18:57:50 nirik: you really don't think the meme 'oh yeah, they replaced yum with dnf' will get out there? 18:57:54 hah, we still package mach 18:57:54 drago01: we are. 18:57:58 drago01: We don’t actually precisely know because the deps don’t track this 18:58:04 i mean, we used to use up2date, remember? 18:58:09 and pirut! 18:58:09 no. ;) 18:58:15 EXACTLY 18:58:20 I have drunk those memories away. 18:58:29 look, the internet still talks about stuff from RHL9 18:58:32 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 well, those things were not that similar to what replaced them 18:59:12 imagine a world where we've built up the rings idea into atomic baseOS+DE/Server layers 18:59:13 adamw: Well, the new thing isn't that new for quite some people. 18:59:14 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 do you think we're going to wrap 'atomic host upgrade' with yum too? 18:59:37 adamw: For the simple install, update case you can trivially replace yum with dnf. 18:59:42 why isn't this a concern there? 19:00:01 jwb: Because atomic isn't about packages? 19:00:12 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 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 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 mitr, today, yes. in the future, that may not be the case 19:01:23 sgallagh: and it tells them to look at those. ;) 19:01:29 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 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 jwb: What might not be the case tomorrow? (1) or (2) ? 19:01:45 I'd somewhat rather we just put the nag comment on the real yum and just washed our hands of it 19:01:48 FWIW, I'm also for just making the swap and being done with it 19:01:49 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 rishi, that's a tangent that probably isn't going to help this conversation so i'll just let it go 19:02:17 anyhow, I guess I can make the devel list post and everyone can flame on there. 19:02:54 nirik: We're in Freeze. Do we really want to wait to wade through a flamewar before deciding on this? 19:03:00 If we are freezing Beta with this, would we still consider reverting? 19:03:02 sgallagh: we already decided this. 19:03:09 unless someone is putting out a new proposal 19:03:16 nirik: I wasn't around that day. And yes, I am. 19:03:24 ok 19:03:40 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 you decided it twice, didn't you? 19:03:40 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 adamw: at least 19:04:13 sgallagh: clarification... what is 'the real yum binary' ? 19:04:16 adamw, we did. in different ways. 19:04:20 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 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 sgallagh: … and ship yum in the minimal install? Or leave /usr/bin/yum missing? 19:04:24 how about this again (somehow got lost) "DROP the real yum binary" 19:04:26 nirik: /usr/bin/yum as provided by the 'yum' package 19:04:33 adamw, not all. 19:04:34 replace it with a symlink to dnf or dnf-yum 19:04:35 done 19:04:45 jwb: sorry, was using it in the Texas sense. 19:04:47 adamw: I was against it as it was orig setup... with dnf-yum conflicting with yum 19:05:02 drago01: That was already proposed on the ticket. 19:05:07 And apparently we are not happy with it. 19:05:11 drago01: Strictly worse than all of the other alternatives, breaks software and leaves it scrambling to port to yum 19:05:29 .. port to dnf obviously 19:05:36 mitr: "break software" ? 19:05:39 adamw: when the change was improved, the question of what would be the new /usr/bin/yum was left unanswered 19:05:47 if the software is using the yum api it should work fine 19:05:50 its still present 19:05:54 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 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 And then kill off the package entirely there. 19:06:30 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 sgallagh, that won't lead to dnf being the default. 19:07:11 it will lead to people still using yum in f22 and then hitting the pain point in f23 19:07:20 FYI, if anyone cares the '/usr/bin/yum' message is: 19:07:23 yum list foobar 19:07:23 Yum command has been deprecated, use dnf instead. 19:07:23 See 'man dnf' and 'man yum2dnf' for more information. 19:07:23 To transfer transaction metadata from yum to DNF, run 'dnf migrate'Redirecting to '/usr/bin/dnf list foobar' 19:07:23 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 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 drago01: yes 19:07:46 sgallagh, because people will ignore the nag and still type 'yum'?? 19:08:26 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 '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 this is not a *minor* behaviour difference. 19:08:58 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 adamw: is there any software that tries to parse the yum output? 19:09:09 that would be beyond crazy 19:09:10 i don't know. 19:09:15 I'm sure there is. 19:09:19 the point is they differ in behaviour in significant and obvious ways. 19:09:25 ugh 19:09:29 as jwb said, they are *not* the same thing. one should not pretend to be the other. 19:09:40 people with software parsing the yum output are already used to that output changing from yum version toversion. 19:09:44 the dnf devs dropped the goal for dnf to be a precise replacement for yum in any way years ago. 19:09:47 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 rishi: which blocker? 19:10:04 mattdm: yeah that's not really something that ever was guaranted to be stable 19:10:10 nirik: https://bugzilla.redhat.com/show_bug.cgi?id=1156491 19:10:24 thats a tracker... not a blocker. ;) 19:10:35 Sorry, terminology. 19:10:46 http://ghantoos.org/2008/09/28/yum-output-parser/ ... 19:11:16 "The script is quite easy to use" 19:11:26 * dgilmore needs to run and pick up daughter from School 19:11:41 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 unfortunately i have a hard stop in 10min. fortunately, i don't really have anything further to add to the conversation 19:12:04 jwb: but at least we had some contention! :) 19:12:16 yes! 19:12:21 nirik: Yeah. 19:12:26 The subjects suck. 19:13:46 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 nirik, +1 19:14:09 paragan: What are you +1ing? 19:14:32 sgallagh, to nirik's proposal to have new dnf packages in F22 Beta 19:14:41 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 rishi: We are not going to analyze all of the 35 here 19:15:14 I am -1 to reverting this again; let’s go with /usr/bin/yum taken over by yum-dnf 19:15:18 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 heh 19:18:02 was something proposed? 19:18:02 Any other topics for to discuss today? 19:18:12 (he regrets asking) 19:18:21 ajax: [13:03:40] 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 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 ... that is more useful than going around in circles. :) 19:19:00 i only recall voting on this issue once? 19:19:01 I think we could revist after beta too... it shouldn't be difficult to change it... 19:19:08 which i think is because it predates my term 19:19:13 if there's some unseen well of doom. 19:19:16 So I will log my displeasure and withdraw from the discussion. 19:19:18 but i don't see a lot of point in reverting so -1 to that 19:19:36 and i think that's even consistent with how i voted the first time! 19:20:46 Anything else to discuss? If not, I will close the meeting in 2 minutes 19:20:59 nothing from me 19:21:09 * nirik has nothing 19:21:20 Nothing. 19:22:53 Thanks, everyone! 19:22:56 #endmeeting