17:02:15 #startmeeting FESCO (2014-07-23) 17:02:15 Meeting started Wed Jul 23 17:02:15 2014 UTC. The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:17 #meetingname fesco 17:02:17 The meeting name has been set to 'fesco' 17:02:19 #chair abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones sgallagh t8m jwb thozza kalev 17:02:19 Current chairs: abadger1999 dgilmore jwb kalev kylem mattdm mitr mmaslano nirik pjones sgallagh t8m thozza 17:02:21 Hello everyone. 17:02:23 Now that the election results have been published, do we want to apply the membership change to this meeting already? Let’s see who is around first… 17:02:25 #topic init process 17:02:31 hello! 17:02:32 mitr: that's how it's worked in the past. 17:02:40 hey 17:02:40 hello everybody! 17:02:45 * nirik is only slightly around, but can try and follow things... 17:02:49 yeah let's make welcome new people as first agenda item? 17:02:52 Hey everyone 17:02:54 mitr: by which I mean: Sayonara, suckers! 17:03:06 :-) 17:05:19 hi 17:05:27 * jreznik is here for fesco :) 17:06:17 hi 17:07:04 Let’s get started then 17:07:13 #topic Welcoming new FESCO members 17:07:51 #info Welcome new FESCo members, Josh Boyer, Tomas Hozza, Kalev Lember! 17:08:16 welcome indeed. 17:08:39 hello hello 17:08:40 and many thanks to abadger1999 aand pjones for their service. 17:08:45 yes, welcome and thanks! 17:08:49 #info Thanks to the previous members Peter Jones, Toshio Kuratomi, Bill Nottingham, for their service 17:08:49 and notting :) 17:09:01 * abadger1999 waves good bye :-) 17:09:04 And kylem's week, right? 17:09:06 thanks to all previous members :) 17:09:21 oops 17:09:23 #undo 17:09:23 Removing item from minutes: INFO by mitr at 17:08:49 : Thanks to the previous members Peter Jones, Toshio Kuratomi, Bill Nottingham, for their service 17:10:09 Thanks to the previous members Peter Jones, Toshio Kuratomi, Bill Nottingham, Kyle McMartin for their service 17:10:16 btw. I sent erratum with correct terms information, sorry for mistake, it came from the ticket, elections announcement right up to the results email 17:10:17 #info Thanks to the previous members Peter Jones, Toshio Kuratomi, Bill Nottingham, Kyle McMartin for their service 17:10:47 * mattdm takes responsibility for being wrong in the ticket. sorry! 17:11:15 one thing I did - updated the FESCo member list with terms people were elected for 17:11:29 Since we have 2 members present both newly elected and departing, and given past practice, let’s continue with voting by the new members. 17:11:32 so it should be now much more visible/trackable 17:11:48 jreznik good call 17:12:03 * nirik updated the fesco list, let me know if I missed anyone 17:12:59 #topic #1178 Fedora 21 scheduling strategy 17:13:01 .fesco 1178 17:13:04 mitr: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 17:13:50 so as stated in the ticket, we are not ready to freeze (as it was planned for this Tuesday) 17:14:04 sadly I have to agree we need to slip, I think we are getting closer to resolving the issues 17:14:07 several issues, the most imporant is we even don't have full test composes available 17:14:18 it seems kind of like _far_ from ready. 17:14:25 so now the questoin is for how long 17:14:40 as much as I hate to slip, I don't think there much choice here since the images are so much behind 17:14:56 Might we need to slip _more_ than two weeks? 17:15:05 to be honest, I agree with tflink 3 weeks with one week for Flock... 17:15:22 not to repeat f18 slipping by week when we already knew it's not enough 17:15:24 * dgilmore will be in Brno next week but the week after busy with Flock 17:15:27 * tflink is actually more for 4 weeks but 3 is better than 2 17:15:28 I also agree with the concern pointed out in the comment #52 17:15:37 (flock) 17:16:02 one option might be to try and have 2 weeks unfrozen time between milestones, instead of the 3 unfrozen weeks we have now 17:16:26 so we'd slip alpha freeze by three weeks 17:16:32 but beta freeze only by 2 weeks 17:16:36 as long as we don't repeat f18, that could work 17:16:36 and final freeze only by 1 week 17:16:44 I feel like any attempt to squeeze future milestones is just lying to ourselves 17:16:51 yep 17:16:53 Is the concern that we are in to bad a shape _now to freeze_, or that we _will be in a bad shape after the freeze_? 17:17:18 mitr we are definitely in bad shape now to freeze. I can't speak to the other. 17:17:28 mitr: the main concern is - it doesn't make sense to freeze and make it difficult for everyone when we know, we are not yet there 17:17:30 i.e. if there were no Flock, would we be happy enough with moving the freeze to Aug 5? 17:17:52 mitr: I hope so, but with Flock, it's really 3 weeks 17:18:07 jreznik: My point is really, that if we are _frozen_, there shouldn't be that many people we _need_ to work on the code so the impact of Flock shouldn’t be _that_ severe. 17:18:13 and I'd really like to avoid mangle with freezes for upcoming milestones now 17:18:27 mitr: all our qa folks are very busy during freeze testing. 17:18:29 (OTOH if everyone we need for the post-freeze work will be busy at Flock, then there is really no point.) 17:18:55 nirik: Good point, and it’s QA asking for the extension. 17:19:03 I hate to see the overall schedule leaving halloween and landing on thanksgiving 17:19:46 a bunch of Workstation key people are also going to be at Flock and can't help fix blockers if things come up 17:19:47 mattdm: we already made it on thanksgiving once, not ideal but 17:19:52 But, whelp, if we need the time, let's take it and make sure this comes out right. 17:20:01 I'd hate to see another f18 more than I'd hate to see us slip the final release 17:20:03 we still have a slight margin left. 17:20:08 * mattdm throws salt over shoulder 17:20:19 tflink++ 17:20:29 tflink: so January? :) 17:20:33 the insanity around f18 is a great way to burn people out and lose contributors (in qa and releng, at least) 17:20:36 jreznik-- 17:20:59 jreznik: if the choice really came down to releasing in Januare instead of f18.next, yes 17:21:03 dgilmore: when do you expect you'll sort out compose issues? 17:21:17 jreznik: no idea. 17:21:23 dgilmore: and is there anything that we can pull in more help on? 17:21:26 I think i have sorted some of them this morning 17:21:34 it seems like a critical bottleneck.... 17:21:43 (test composes, I mean) 17:21:50 bcl might be able to help if it's the same livecd-creator issue? 17:22:16 mattdm: the main issue right now is that things are randomly failing but when i run them to debug they work 17:22:17 yeah, without test composes, we can talk about x weeks slips but that means we don't have any data in hand and it's blind guessing 17:23:08 32 bit composes seem to be workinga gain 17:23:10 again 17:23:22 good to hear 17:23:43 they were failing for the last week 17:24:14 perhaps we could push 2 weeks now, and revisit then before going into freeze? 17:24:29 dgilmore is there someway someone could help? 17:24:29 nirik: thats okay by me 17:24:30 what's the point of going into freeze the day before flock? 17:24:46 mattdm: im pulling in people to help with the issues 17:25:13 tflink: whats ever the point of freeze? to keep people from pushing in changes that don't fix blockers, stablize the tree 17:25:18 dgilmore: okay good. just making sure that you weren't feeling left on your own there 17:25:32 now, granted many will be traveling and at flock and so wouldn't anyhow... but... 17:25:32 mattdm: I am not 17:25:37 nirik: I think we have to go that way at least skipping flock 17:25:41 nirik: sure, but freeze adds process weight and tends to annoy packagers 17:25:44 dgilmore cool 17:26:07 mattdm: and once we have sorted out fedora.next composes ill be making sure that there is other releng folks capable of doing them 17:26:14 so I am nota bottle neck 17:26:17 I don't care (too much) about annoying packagers -- but I would like the releng and qa people to be able to participate fully in flock without other obligations 17:26:30 if a good chunk of the qa regulars aren't going to be testing until after flock, I don't think that our chances of hitting the alpha release a week after flock are very good 17:26:32 tflink: sure... and it does mean there would be TC/RCs so people might feel like they need to test instead of being at flock 17:26:59 dgilmore Wasn't trying to call you one -- the composes themselves are the bottleneck 17:27:19 mattdm: right 17:27:21 * nirik sees tflink's point. perhaps we do 3 weeks now and recheck then 17:27:32 but I kinda am, and I dont want it to be so 17:27:42 +1 to nirik's proposal 17:27:47 dgilmore: *nod* 17:28:02 btw with two weeks and release on 18th, it means we would have like a three days for real work after flock 17:28:27 I am for slipping the alpha freeze for 3 weeks if we slip now -- but can we make the unfreeze time between milestones 2 weeks instead of 3 to make up for some lost time? 17:29:31 kalev: I don’t think historically that worked very well; people need time to install the test release and report bugs, and people need time to triage and fix bugs. 17:29:43 But I don’t recall exactly when we last tried this. 17:29:45 from a qa perspective, I'm not against the idea as long as you're flexible about extending that if it's needed 17:30:09 mitr: I think it was f18... but we had... other problems then. 17:30:11 entering freeze with badly broken stuff in the hope that it'll somehow get fixed in 2 weeks generally doesn't work all that well 17:30:56 can someone mock out what kalev's proposal would be date wise? 17:31:04 * kalev tries. 17:31:19 * tflink doesn't care so much about when the dates are - more about making sure we have a snowball's chance of actually releasing 2 weeks after the freeze starts 17:31:34 tflink: well, holidays and such need to be avoided. 17:31:49 I guess... does having a three week time mean people think "oh plenty of time" and do all the work in the last week anyway? 17:31:54 nirik: true, I hadn't been thinking about that 17:31:55 I suppose I’m +1 to nirik’s proposal (slip 2 weeks now, and reevaluate next week); if everything were in great shape next week, we won't need to slip too much—but we should be very ready to slip more. (I’m not actually concerned about slipping a week at a time, at this point we don’t have any Change we would definitely keep slipping for unlike f18) 17:32:07 I think 2 weeks unfrozen at least between alpha and beta is too short 17:32:23 mitr: I think nirik said 3 weeks 17:32:29 nirik: this is how it would look with 2 weeks: http://fpaste.org/120222/06136711/ 17:33:10 jreznik: oh, right. I missed the update. 17:33:47 kalev: one big note in the schedule file from poelstra is - don't try to play with milestones, just slip... we did it for f18 and it was mess in the end 17:33:53 yeah, tflink talked me into 3. ;) 17:34:04 ill go with QA 17:34:07 I'm +1 to 3 week slip, no built-in make-up time... I think trying to squeeze later just means we'll have to slip another time. 17:34:25 I think it would make more sense to decide on the shortening once we get there and see how ready we are 17:34:43 mattdm, +1 17:34:45 thozza: you mean unslip_ the schedule? that would be novel :) 17:35:27 yep I don't see a big chance to do the unslip but we might try :) 17:35:27 mattdm: I mean slip now after Flock, but leave the rest of the schedule (time period, not dates) the same 17:35:43 thozza: you can't do that! 17:35:58 thozza: ah, I understand - yes, it's the plan 17:36:48 so votes? 17:36:58 So, formal votes on 3 week slip? I count mattdm, t8m, unsure about nirik and dgilmore (please confirm explicitly) 17:37:08 I am +1 for 3 week slip 17:37:26 +1 for 3 week slip 17:37:28 +1 17:37:29 I’ll go with what QA asks for as well, +1 17:37:55 +1 17:37:57 +1 for 3 week slip 17:38:26 we should make clear that in addition to not being ready for alpha freeze we also wanted to make sure flock wasn't a busy time for folks. 17:38:30 #agreed Slip the schedule 3 weeks, per http://fpaste.org/120222/06136711/ (+7) 17:38:46 nooo, undo this 17:38:57 the fpaste above was a different proposal 17:39:00 mitr, this is with the shortening 17:39:02 with 2 weeks between releases 17:39:06 #undo 17:39:06 Removing item from minutes: AGREED by mitr at 17:38:30 : Slip the schedule 3 weeks, per http://fpaste.org/120222/06136711/ (+7) 17:39:20 #agreed Slip the schedule 3 weeks (+7) 17:39:41 #topic #1322 Changes - Progress on Changes Freeze 17:39:43 .fesco 1322 17:39:44 mitr: #1322 (F21 Changes - Progress on Changes Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/1322 17:39:45 There are no updates on this ticket; does anyone have a concern to discuss, or shall we move on? 17:39:57 mitr: ok, I'll update schedule and announce slip 17:40:16 #action jreznik to update schedule and announce the slip 17:40:18 jreznik: thanks! 17:40:39 jreznik: cheers 17:41:09 Moving on… 17:41:15 #topic #1325 packagers doing dodgy things in review 17:41:17 .fesco 1325 17:41:18 mitr: #1325 (packagers doing dodgy things in review) – FESCo - https://fedorahosted.org/fesco/ticket/1325 17:41:41 so, I do think that package reviews are sometimes dodgy and people just set fedora_review+ without actually reviewing anything 17:41:53 but in this case, I think it's all good and even better than in the average review 17:42:04 two people were working on the package and reviewing each others changes and fixing actual issues the other found 17:42:13 they probably didn't follow the package review process to the _letter_, but they definitely followed the _spirit_ of the process by having two people review each others changes 17:42:26 I think the review was done but not exactly formally according to the process 17:43:15 kwizart: we've had this so far: http://fpaste.org/120227/06137379/ 17:43:16 I think it was a little bit confusing, but not to the point that they deserve any kind of punishment 17:43:16 So I definitely do not see a need to do any punishment against the reviewer+maintainer 17:43:26 and there was also some misunderstanding 17:44:06 there is no indication that the review was done 17:44:17 that sources were verified 17:44:18 t8m: well we don’t know because we don’t have the written record (pasted rpmlint etc.) we require precisely to know :) 17:44:21 kalev, thx for the spirit, indeed formalism is missing, 17:44:24 that licenses were checked 17:44:36 and that they switched like they did mid review is not okay 17:44:38 I know we don't require checklists or anything, but it always makes me nervous when a reviewer says "looks ok, approved" 17:44:40 we have policies 17:44:49 dgilmore: IMHO switching is perfiectly OK if it is clear that it happened. 17:44:50 the bug should have been closed and a new one opened 17:45:00 dgilmore: the only think we actually require is pasting rpmlint, not any of the checklists that some people do paste. 17:45:29 I don't think we have ever mandated the fedora-review checklist 17:45:29 (Which is kind of nonsense, but then we should be automating this instead of adding more manual steps, so…) 17:45:31 mitr: right, there is generally some indication that a review was done 17:45:39 mitr, +1 17:45:41 in this case I do not believe it was at all 17:46:41 So what now? Ask for an explicit fedora-review checklist processing? Ask them to find a third reviewer? 17:46:41 the bug should have been closed and a new one opened, agreed, but why raising fesco about this ??? and not writting directly to me ? 17:46:59 kwizart: because it was shady what was done 17:47:30 dgilmore, like when I'm reviwring the uboot patches ? 17:47:32 mitr: I think at the least someone else should review the package 17:47:43 kwizart: ? 17:48:02 * nirik thinks it was just miscommunication... 17:48:38 sorry for others eyes , but few days ago i've submitted an issue on uboot non-upstream patches added that broke my system 17:48:46 sooo, I think the missing thing is step 5 in http://fedoraproject.org/wiki/Package_Review_Process#Reviewer 17:48:47 I want to know if this is linked ? 17:48:57 "Include the text of your review in a comment in the ticket. For easy readability, simply use a regular comment instead of an attachment. " 17:48:58 And ausil is the maintainer 17:49:16 kwizart: ausil is me 17:49:22 that doesn't mean pasting the fedora review, but at least some text assuring that the basics are covered 17:49:34 https://bugzilla.redhat.com/show_bug.cgi?id=1119741 17:49:55 yes we know who is ausil 17:49:57 soooo... proposal: new reviewer to make sure that is done in this ticket, and, gentle reminder to do that in the future? 17:50:10 kwizart: all those patches were on their way upstrema 17:50:12 upstrema 17:50:15 upstream 17:50:22 kwizart: and its off topic for this 17:50:33 mattdm: +1 17:50:45 mitr: +1 17:50:48 dgilmore, fait enought if you said i's offtopic, 17:51:08 kwizart: we don’t do reviews of packaging after the initial review (regrettably?) 17:51:31 mattdm: +1 (where “do that” is “do reviews in a documented transparent way",. not “always find a 3rd party if these two people meet in a review”) 17:51:45 kwizart: we are talking about the package review not u-boot 17:52:01 mitr yes :) 17:52:50 dgilmore, fait enought if you said it's offtopic, it could have be a personal issue with me 17:53:23 same with xorg-x11-drv-freedreno, you have explicily removed my acl without any reason ? 17:53:28 kwizart: its not an issue with you, though I do wish you would be open and talk about what it is your doing and wouldnt step on peoples toes all the time 17:54:09 quote ? 17:54:53 kwizart: there was indeed no clear acknowledgement of successful review in the comment 17:55:22 More votes? 17:55:49 +1 for mattdm proposal with mitr's note 17:55:55 thozza, I agree with redoing the review, formalism was missing, I appologies, but I don't understand why this was raised to fesco 17:56:10 +1 same as thozza 17:56:11 * mattdm is +1 to own proposal, including mitr's note 17:56:40 kwizart: I see, however what's done is done. let's deal with it 17:56:42 if it's missing communication with ausil, I want to clear that 17:57:11 #agreed new reviewer to make sure that is done in this ticket, and, gentle reminder to do reviews in a documented transparent way in the future (+5) 17:57:31 kwizart, dgilmore: clearning that up seems like a great idea but let's not do it right here right now 17:57:55 #topic Next week’s chair 17:58:15 ok I still needed to raised this point publicly, thx for your decision 17:58:18 Actually, before that: kalev, thozza: Are you OK with this meeting time, or shall we do a new whenisgood round? 17:58:27 mitr: works for me 17:58:59 no idea about jwb though 17:59:04 mitr: I doubt we can find better time that will suite everybody 17:59:14 but can try 17:59:36 OK, one more round won't hurt. 17:59:39 jwb often has dropped in on the meetings around this time (or at least when it was an hour later) 17:59:51 #actinon mitr to send a whenisgood 18:00:34 #info The next FESCo meeting will happen in the currently scheduled time, whenisgood results to apply starting the week after. 18:00:40 Now, anyone to chair the next meeting? 18:01:19 I'll be at guadec next week, might be missing from the fesco meeting because of that 18:01:50 I'm *really* trying to avoid any new commitments before flock :) 18:02:05 * thozza unfortunately wont be available next week at this time (traveling) 18:02:35 I guess I could. 18:02:39 I will be on holidays next week 18:03:10 are we even going to have quorum next week? 18:03:17 * dgilmore will be in Brno next week and not sure what exact availability he will have 18:03:23 sounds like perhaps not 18:03:52 So far 3 missing, so we could lose one more. 18:04:29 #info nirik to chair the next meeting 18:04:33 nirik: Thanks! 18:04:39 #topic Open Floor 18:04:43 thanks niriik! 18:04:51 Anything else to discuss today? 18:05:00 anyone else going to guadec? 18:05:05 Should we change the fesco replacement policy permanently? 18:05:17 eg: in the event of open seats, we hold a special election? 18:05:52 mattdm: sounds reasonable 18:05:58 mattdm: perhaps. Might be worth a bit more thought than just doing it in open floor tho? file a ticket for next time? 18:06:23 nirik: okay, sounds fair 18:06:58 and it might be good to discuss it with the fedora board first 18:07:16 kalev: sure 18:07:44 kalev: as the same could apply to board too (and famsco) 18:07:49 yeah 18:09:24 mattdm, this should be a decision of board, shouldn't it? 18:09:47 mattdm, I think FESCo should not change rules of its own elections by themselves 18:09:52 t8m: FESCo can come with the Board to a proposal that we think would be suitable, though. 18:10:04 t8m unclear. I think we can come up with a proposal 18:10:13 sure we can 18:10:15 t8m: (Historically FESCo predates the board so the rules are unclear but having the Board ratify seems reasonable.) 18:10:23 here, the intention is for it to be _more_ democratic, so I don't think there's any problem 18:10:55 yep, but I'd like to see formal ratification by Board 18:11:19 t8m sounds good 18:11:49 https://fedorahosted.org/fesco/ticket/1326 18:11:56 Anything else for open floor? 18:12:36 If not, I’ll close the meeting in 2 minutes… 18:14:02 schedules are updated but I have to go now, I'll send announcement later today 18:14:40 Thanks everyone! 18:14:41 #endmeeting