17:04:28 #startmeeting FESCO (2014-08-20) 17:04:28 Meeting started Wed Aug 20 17:04:28 2014 UTC. The chair is thozza. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:04:28 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:04:36 #meetingname fesco 17:04:36 The meeting name has been set to 'fesco' 17:04:43 #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:04:43 Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:04:48 #topic init process 17:04:52 Hello everyone 17:04:56 hello 17:04:57 hi 17:05:02 mmorning 17:05:06 Hello folks. I'm here but juggling the blockerbugs meeting and other fires. 17:05:43 hi 17:05:50 hi, im working on getting things in place for a TC compose 17:05:58 and wont be paying much attention here 17:06:57 lets wait a minute and then start 17:07:33 for those who aren't following #fedora-devel, I just noticed that the last mass rebuild might have used a bad rpm build 17:07:54 dgilmore just tagged it over and several packages seem to have lost all provides / requires 17:08:07 kalev: that's bad news :-( 17:08:07 unknown how many packages might be affected at this point 17:08:12 kalev: not really the right time to bring it up 17:08:28 ok, lets start 17:08:32 dgilmore: ? FESCo should be on top of things. 17:08:36 #topic #1178 Fedora 21 scheduling strategy 17:08:43 kalev: open floor 17:08:51 kalev: we have an agenda 17:09:02 … actually _now_ seems to be is just the right time :) 17:09:22 yes 17:09:43 Do we know that we need to change anything already, or is it just too unknown? 17:10:59 well, a few things are definitely broken 17:11:06 some packages will have to be rebuilt (both in F21 and rawhide), but unknown at this point how many 17:11:08 the fix is already in, so they would just need rebuilding 17:11:43 Given that the bug was present for the entire run of the mass rebuild, we're in bad shape. 17:11:53 sgallagh: it wasn't actually. ;) 17:12:02 it landed on the 18th. at the end of the mass rebuild. 17:12:03 Oh, even better :-/ 17:12:19 and only things with external dependency overriding 17:12:35 Ok, that's less threatening. 17:12:56 still nasty, but hopefully not crippling. ;) 17:13:37 so, we could slip another week now, or we could try and wait for a somewhat complete looking TC and freeze after we get that. 17:14:22 I think we need some date anyway 17:14:36 here, sorry 17:14:36 not just wait without any particular estimate 17:14:59 We could also freeze right now and just grant an automatic freeze exception to packages that hit this bug. 17:15:10 thozza: true I guess. I was just hoping we could get a TC in the next day or two and freeze then while things work. ;) 17:16:41 nirik: then sgallagh's idea could be usable? 17:16:45 The current schedules seems to say go/no-go meeting is on Aug 25, that gives us still a few days in which we could freeze and not have to slip 17:17:08 I don't think there's a need to freeze on a specific date an it would be fine to say that we are freezing the next day after a successful TC 17:17:29 If it can be so, I'm for it 17:17:31 as long as we send a heads-up to the devel list when we know the exact date 17:17:42 we should know better how thinsg look later today 17:18:02 I'm leary of freezing before we have an actual usable TC 17:18:08 same 17:18:16 yes 17:18:49 proposal: Revisit schedule next week, don’t actually adjust it today. 17:19:01 +1 17:19:08 mitr: well, if we do that we should have frozen yesterday and didn't. ;) 17:19:33 addendum: don't freeze 17:20:42 I would like us to go in a release mode and freezes once things look relatively OK, just to not lose any extra time 17:21:19 so we should also add "freeze as soon we have usable TC, send heads-up to devel list a day before"? 17:21:46 makes sense to me 17:21:58 proposal: go into freeze the day after we have a usable TC. revisit schedule next meeting to see if we need to adjust/delay/change anything. 17:22:07 nirik: +1 17:22:09 nirik: +1 17:22:10 nirik: +1 17:22:16 who will do the heads-up? 17:22:32 releng since they know best when composes are actually working? 17:22:58 ok 17:23:05 dgilmore: can you do it? 17:23:23 thozza: sure 17:23:28 since releng also does the stuff to start the freeze, makes sense to me. ;) 17:23:34 thanks 17:23:42 nirik: +1 17:24:17 #agreed Go into freeze the day after we have a usable TC. revisit schedule next meeting to see if we need to adjust/delay/change anything. (+5) 17:24:23 +1 17:24:35 (sorry, distracted atm) 17:24:48 #undo 17:24:48 Removing item from minutes: AGREED by thozza at 17:24:17 : Go into freeze the day after we have a usable TC. revisit schedule next meeting to see if we need to adjust/delay/change anything. (+5) 17:24:56 #agreed Go into freeze the day after we have a usable TC. revisit schedule next meeting to see if we need to adjust/delay/change anything. (+6) 17:25:24 #action dgilmore will send the heads-up on devel list once we have TC (day before freeze) 17:25:43 #topic #1322 F21 Changes - Progress on Changes Freeze 17:26:52 jreznik is missing... I guess no updates? 17:26:53 not sure where we are here... 17:27:09 I think yeah, jreznik was going to ping folks and give us an update. 17:27:13 perhaps we should note that in the ticket? 17:28:14 nirik: ok, I can update the ticket 17:28:26 thanks 17:28:58 #action thozza will update the ticket asking for update on Changes progress 17:29:03 moving on.... 17:29:12 #topic #1330 F22 System Wide Change: Perl 5.20 - https://fedoraproject.org/wiki/Changes/perl5.20 17:29:29 +1 17:29:42 +1 17:29:45 thozza: +1 17:30:00 +1 17:30:01 sure, +1 17:30:03 +1 17:30:39 we had a bunch of high profile side tags landing at the same time this cycle, boost and python and tcl and something else 17:31:06 might be nice to have deadlines for each of those that are like a week apart, to be able to land them one by one 17:31:25 * nirik nods 17:31:56 yeah. probably something we could note for the Change owners to work out with rel-eng 17:32:56 We ill have Python 3 and DNF this cycle, so enough fun for everyone 17:32:57 should we note in the ticket? I think email to all those owner would be better 17:33:26 A ticket should be sufficient, that sends email to the requester as well. 17:34:18 OK, I'll note that in the ticket when updating 17:34:42 #agreed F22 System Wide Change: Perl 5.20 has been approved (+6) 17:34:56 #topic #1331 The package pipelight violates Fedora guidelines regarding 17:35:35 looks like it's already resolved 17:35:58 i don't think there's anything realistic for us to do here 17:36:06 yeah, been removed. 17:36:17 there is the last comment, about the maintainers other behavior... 17:37:17 The reason I added it to meeting was comment #5 17:37:25 I was going to chat with the approver of the package, but I wanted to make sure no one else in FESCo had already taken it upon themselves first. 17:37:38 * nirik hasn't. 17:37:43 * kalev hasn't. 17:37:44 I didn't 17:38:26 so, yeah, talking to the review approver, and also talking to the maintainer might be good ideas... does someone want to talk to the maintainer? 17:38:46 #action sgallagh to discuss proper review policy with the approver. 17:39:14 As for #5, I strongly think that adding more layers of manual review to avoid such cases is not worth it. 17:40:07 mitr: I agree 17:40:26 Yeah, we've already got review policy that was just not followed here. 17:40:34 (Probably not maliciously, I hasten to add) 17:41:14 additionally it could have/should have been caught when adding it to scm... 17:41:34 I think it was the reviewer job 17:41:43 I think we could talk to the (former) maintainer of the package about the items in comment #5 and ask them to be more carefull? 17:42:04 nirik: Isn't addition to scm an automated task? 17:42:45 It might be worth it to check that the packaging guidelines and/or the fedora-review template is explicit enough, but that’s a …copywriting? rather than policy issue 17:43:17 * sgallagh nods 17:43:52 sgallagh: nope. It's scripted, but a real human doublechecks that the review is ok and everything was done properly. 17:44:10 the problem of course is that sometimes there's tons of them and it's hard to catch everything. 17:44:20 Interesting. I wasn't aware of that. 17:44:39 as for #7 and the package submitter changing Wine, I do like that we have provenpackagers that are actually able to touch other packages and fix / improve things ... at least in Rawhide 17:44:44 "Introduced large patchset /.../ to F19" seems wrong on many levels though, stable releases should not get experimental stuff, no matter what it is 17:45:56 Well, it seems like this person may have been misusing his provenpackager permissions. 17:46:22 Perhaps we should declare him "on probation" with a warning that a repeated offense will cost him his provenpackager powers? 17:46:57 sgallagh: seems fair to me, since it was most probably intentional 17:47:42 sgallagh: I wouldn’t want to overreact (and especially invent new provenpackager states :) ) 17:48:02 thozza: I'm not sure his intentions were *malicious*, but they were not in line with the best interests of Fedora. 17:48:27 * nirik thinks we should talk to them first... we only have one side here. 17:48:38 True enough 17:49:11 yeah, I don't want to overreact either and lose a provenpackager that does tons of good work 17:50:04 ok, let's stick to the plan of talking to the involved parties for now 17:51:10 who wants to talk to the maintainer then? ;) sgallagh you want to do that too? 17:51:28 Since no one is jumping up and down to do so, I suppose I will 17:52:47 thanks 17:52:50 since I suppose there is nothing to vote for in this ticket, lets move on.... 17:53:22 #topic #1332 F22 retire orphan packags after 4 weeks instead of once per release 17:53:45 #action sgallagh to talk to maintainer as well (previous topic) 17:55:29 yeah, on this we may need more discussion. see the points raised by dgilmore in the last comment. 17:55:40 I don't know that there's a sufficient advantage to this compared to the additional overhead. 17:55:49 Is retiring for-branch, or for all of them? 17:55:58 per branch. 17:56:18 we don't allow retiring in stable releases I don't think. 17:56:34 I guess the advantage of doing it more often is that we would have less orphans in releases. 17:57:22 * nirik is for discussing this more on list and punting to next week. ;) it doesn't seem urgent. 17:57:32 But the real issue that this proposal is trying to address is that stable releases end up with abandoned packages 17:58:16 I think there are better ways to do some of this (not least is the upcoming improvement to the release monitoring stuff) 17:58:34 But yes, not urgent so let's take it off the meeting agenda for today, please 17:58:49 nirik: AFAICT this is mostly up to rel-eng availability/willingness. 17:58:56 Anyone to move this to the list then? 17:59:21 mitr: +1 17:59:36 well, it could in fact be scripted I think. 17:59:53 person orphans a package... wait 4 weeks, retire 18:01:13 That still doesn't address the issue of people who already have the package installed... but as previously stated, let's not continue this discussion here. 18:03:44 so volunteer to move the discussion to the list? :) 18:03:44 Shall we move on? 18:03:58 * sgallagh has enough action items today already thankyouverymuch 18:04:00 I can, or ask the reported to 18:04:04 reporter 18:04:07 ok 18:04:37 #action thozza ask reporter to move the discussion to the devel list 18:04:48 #topic #1333 OpenJDK maintainer refuses to address F20->F21 upgrade bug once per release 18:05:14 So... yeah. 18:05:23 AFAICT the code has already been written and debugged for 7, and the issue is only that it is too ugly to include in 8 as well? 18:05:47 Short version: if you installed JDK 8 in F20, an upgrade to F21 will break all the alternatives symlinks, leaving your java installation unusable 18:06:08 mitr, yes 18:06:16 mitr: That's the impression I got. There's a patch for the spec that makes it work, but the maintainer doesn't want to include it because it clutters the spec. 18:06:27 sgallagh, yes 18:06:28 In my opinion, this is an insufficient reason to break users' systems. 18:06:32 I remember that we had to explicitly exclude JDK 8 from live images, because dependencies kept bringing it in, over JDK 7 18:06:46 7 is gone in 21+ 18:06:48 wouldn't be surprised if A LOT of users have JDK 8 installed since it seemed to be easy to get it with deps 18:06:51 kalev, but 8 IS main jdk in f21 18:07:11 jvanek: it seems to me that much of the logic that repeats over and over could be moved either into a RPM macro or a helper script. 18:07:11 yeah, this seems really a lot like something that needs fixing. 18:07:20 jvanek: What he's saying is that it's highly likely that many (most?) users will hit this upgrade bug. 18:07:30 if the current solution is too ugly, perhaps we could try and make something better? 18:07:33 yes, I was saying that in F20 context 18:07:47 nirik, If you find, it would be really nice 18:07:49 And in general, "ugly" is not really a good enough excuse for "not solving users’s issues", despite what some people say 18:07:58 But I doubt there is something better. 18:08:14 nirik, One palce where to fix this is fedup. Another may be to rise epoch 18:08:18 jvanek: is the current scriptlet anywhere? a bug perhaps? 18:08:24 but epoch is untested solution for this. 18:08:47 nirik, https://bugzilla.redhat.com/show_bug.cgi?id=1130247#c18 18:09:12 It was added, because in jdk7 those changes were done during the live of fedora 18:09:27 now it is still unrleased software.So Ihope for better solution 18:09:35 * jvanek not yet found 18:09:59 jvanek: Just exploring the options - the F≤20 version isn’t set in stone; could adding a special F20 update make it easier? 18:10:23 mitr, If people will not nstall this update, or will jump directly from f19? 18:10:25 noop :( 18:10:50 jvanek: so add a f19 update as well; I was under the impression (correct?) that we only support upgrades from fully updated systems 18:10:52 We don't actually (officially) support the Fn->Fn+2 jump 18:10:59 mitr, well.. yes 18:11:18 IIRC the system is updated before upgrade 18:11:21 Anyway, considering a problem to this solution exists, proposal: Ask jvanek to make f20->f21 upgrades result in a working system, reasonably similar to a clean f21 install. 18:11:56 There are ways to hide that ugliness from the few people who read the spec, while there are no ways to hide the breakage from users. 18:12:00 addendum: FESCo declares BZ 1130247 to be a blocker for F21 Beta. 18:12:17 I have one question to testing of this issue - when fedup wil start to work? 18:12:32 sgallagh: That would be new, but let’s start doing that, yes. 18:12:34 jvanek: As soon as we have a working Alpha compose, I hope 18:12:50 sgallagh: +1 18:12:54 +1 18:12:55 sgallagh, And does you have some eta? I mean day? two? week? 18:13:09 jvanek: A blocker for F21 implies completion by beta freeze 18:13:22 jvanek: fedup is a release criterion for Beta 18:13:40 So by other words now I will wait for fedup, and then you will wait for me? 18:13:47 Beta freeze is currently scheduled for September 23 18:14:00 sgallagh, Well thats long time... 18:14:10 jvanek: Is this impossible to test using (yum upgrade)? I don’t think fedup is doing anything special about Java 18:14:30 Mitr lasttime I tried, it was compaining to non existing repos 18:14:42 mitr It definitley does not 18:14:49 jvanek: We're not trying to force you to fix it this week, just in time for our users not to be in trouble. 18:14:57 https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#To_Fedora_21_pre-release should work 18:15:14 kalev, ok 18:16:02 so ok. I will fix that 18:16:09 jvanek: Thank you. 18:16:15 sgallagh: +1 18:16:22 jvanek: thanks 18:16:23 onemore thing - sgallagh please, before bringing this to fesco, try to attempt to ping maintainer directly 18:16:37 in this case me 18:16:44 jvanek: I communicated with you on the BZ. 18:16:54 yes - two very short comments 18:17:01 From those no one couldnot do an impression 18:17:13 And personal (ITRC) discussion can always be helpfull 18:17:42 I do not intend to block thing intentionally. (in this BZ I made mistake ) 18:18:15 any more votes? 18:18:26 sure, +1 18:18:31 +1 18:18:32 jvanek: Understood. I'll try a more direct conversation next time. 18:18:32 :) 18:18:37 and thanks for coming and talking things out with us jvanek 18:18:38 sgallagh, thank you 18:18:52 nirik, np 18:18:57 +1 for the record 18:19:28 +1 if that was unclear above 18:19:57 #agreed Ask jvanek to make f20->f21 upgrades result in a working system, reasonably similar to a clean f21 install. FESCo declares BZ 1130247 to be a blocker for F21 Beta. (+6) 18:20:04 hope I counted it right 18:20:34 #topic Next week's chair 18:21:21 note: https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#FESCo_blocker_bugs 18:23:04 if no one else I guess I can do it. 18:23:16 nirik: thanks 18:23:56 #info nirik to chair next week’s meeting 18:24:11 #topic Open Floor 18:28:16 * nirik has nothing 18:28:33 * thozza neither 18:29:25 Nor I 18:29:51 if there is nothing for open floor I'll close the meeting in 2 minutes 18:32:06 Thanks for chairing, thozza. 18:32:41 #endmeeting