17:01:02 #startmeeting FESCO (2014-10-29) 17:01:02 Meeting started Wed Oct 29 17:01:02 2014 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:02 #meetingname fesco 17:01:02 The meeting name has been set to 'fesco' 17:01:02 #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:01:02 #topic init process 17:01:02 Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:01:10 hi guys 17:01:19 .hello sgallagh 17:01:19 hi 17:01:20 sgallagh: sgallagh 'Stephen Gallagher' 17:01:22 Hello 17:01:25 .hello kevin 17:01:26 nirik: kevin 'Kevin Fenzi' 17:01:28 morning 17:01:43 hello! 17:01:57 hello 17:02:50 hi 17:03:03 doorbell be right back 17:04:08 * mattdm is back 17:05:34 * crobinso is here about merge review ticket 17:05:36 I think we can begin 17:05:42 #topic #1269 Closing all 'Merge Review' bugs 17:05:42 .fesco 1269 17:05:43 sgallagh: #1269 (Closing all 'Merge Review' bugs) – FESCo - https://fedorahosted.org/fesco/ticket/1269 17:05:54 crobinso: Hello! 17:06:07 mattdm: You were going to schedule a VFAD and then Stuff Happened(TM) 17:06:29 actually I thought dgilmore was going to do that. ;) 17:06:43 * nirik could be mistaken tho 17:06:52 right. that can still be a thing whoever schedules it. 17:06:53 no, that's what i remember as well 17:07:03 OK, I misremembered 17:07:12 well, we keep wanting to finish these... and... never do 17:07:25 which means we do't really want to finish them 17:07:30 I would be fine with just closing the tickets with wontfix too 17:07:34 we are down to 60 unassigned ones. 17:07:36 sorry I may have failed here 17:07:43 http://fedoraproject.org/PackageReviewStatus/MERGE.html 17:07:44 kalev, yes 17:07:44 lets get the VFAD done 17:08:11 nirik: so it's gone from 100+ to 60 since the ticket was filed? 17:08:28 well, 60 unassigned. I guess there could/are some assigned. 17:08:35 So perhaps we can just agree on a day? Maybe make it a big New Year event? 17:08:47 (not literally Jan 1, of course) 17:08:56 sgallagh sounds good 17:09:21 proposal: dgilmore and mattdm to talk out of meeting and coordinate time (probably january) for vfad 17:09:27 I'm fine with trying a vfad, but after that we may want to give up. ;) 17:09:29 Or even push for it as an event at DevConf.cz? 17:09:32 nirik, yes 17:09:35 what happens after the VFAD if a bunch of merge reviews still remain? I mean, someone can do the gcc merge review, but then it may linger for months and just become out of date... like so many others 17:09:51 +1 to giving up on anything that isn't done after vfad. 17:10:05 may file specific bugs for specific issues found, general bug 17:10:14 it seems like it would be more productive to try and come up with some automated checking/fixing over the entire package set. 17:10:16 having looked at the gcc spec several times, i'm not sure it will ever pass a merge review and i'm pretty sure that doesn't matter 17:10:19 +1 for VFAD is the last stand 17:10:41 jwb: agreed, that covers the majority of the remaining reviews IMO 17:10:48 yeah 17:10:52 These are still bugs^Wtasks whether we close them or not, though, I would be very willing to sacrifice them _if_ it bought us automated tools 17:11:36 mitr: yeah, I don't think that closing them will magically bring the automated tools 17:11:37 mitr: I don't see how one follows from the other 17:11:51 mattdm: +1 17:12:34 sgallagh: If we were to had a discussion about automation, I’d very much like to shut up about keeping the bugs open. 17:13:01 maybe the vfad could be about that instead 17:13:07 since it would benefit new packages 17:13:08 we might want to look at "moving package quality improvement process from high-barrier-to-entry to continuious automatic monitoring and improvement" as a more long term thing 17:13:44 jwb: +1 17:13:45 jwb: Is the set of people who would be involved the same? 17:13:57 i have no idea 17:14:04 does it matter? 17:14:04 having automated rpmlint runs doen and logged in a db with error issues filed as bugs or marked for waiving if there is a legitimate reason it is done that way i would go for 17:14:40 where rpmlint is "something a bit smarter than actual rpmlint", or at least "very carefully vetted rpmlint rules", I hope 17:14:54 I can be convinced of this. 17:15:05 right, and checks for specific guidelines changes... etc. 17:15:08 mattdm: perhaps yeah 17:15:28 mattdm: IOW, fedora-review? 17:15:31 or even fedora-review run on all existing packages 17:15:35 right 17:15:40 I think taskotron can run rpmlint (or fedora-review) on updates in bodhi 17:15:48 well, _and then what_? 5000 new bugs? 17:15:52 All of this requires a champion willing to invest a fairly big amount of time, and everyone being careful not to stand in their way. Can we get this done? 17:15:53 taskotron is running rpmlint on all builds 17:15:58 and check for diff between runs 17:16:02 we'd probably need a way to mark expected failures in spec files somehow 17:16:05 mattdm: Yes, why not? 17:16:10 tflink, it is? 17:16:15 tflink, where is it logging the results? 17:16:22 resultsdb 17:16:28 I'm not seeing how replacing 60 bugs which won't be fixed with 5000 bugs which won't be fixed helps anything 17:16:29 well, for these changes I would prefer rawhide over any updates/stable releases. 17:16:33 we just don't have a way to notify maintainers yet 17:16:39 tflink, ah, ok 17:16:39 nirik +1000 17:16:50 tflink: how do we plan to get that into the devs faces? 17:16:55 mattdm: alternative for lots of things broken: 1 bug and provenpackages just fix them all. 17:17:07 https://taskotron.stg.fedoraproject.org/resultsdb/results?testcase_name=rpmlint 17:17:17 dgilmore: fedmsg integration, probably 17:17:20 nirik sounds good. goes back to needing a champion 17:17:23 but yeah, those kind of changes need a champion 17:17:27 yep 17:17:34 do we _have_ someone interested in being that? 17:17:41 * mattdm looks pointedly at mitr 17:17:51 dgilmore: I misread your question - our plan is fedmsg and fmn 17:17:54 mattdm: If the general assumption is that filed bugs don’t get fixed, we might just as well pack this up and go home. This helps in not needing human reviewers (for those 60 bugs, _and_ the thousand packages coming in the future). 17:18:02 the problem is that it could be more than a full time job... ;) 17:18:35 we also don't have (m)any rules on which rpmlint errors constitute a "failure" 17:18:45 mitr okay, I can buy that. 17:18:47 first step would be to get a process in place, then make it so it would be easier for someone to be a champion for 1 thing 17:18:48 mattdm: Sorry, I can’t find the time now (certainly in the next month), and I don’t really have the expertise. 17:18:52 ATM, the task is written such that any E from rpmlint fails the task 17:19:05 yeah, sometimes rpmlint is just... wrong. 17:19:06 another option would be to look at rpmgrill 17:19:30 if we wanted to use rpmlint, we'd need to take ownership of rpmlint and edit its rules so that its errorss match up with what's considered a package review failure 17:19:30 mattdm: It seems to me fedora-review would be a natural starting point. 17:20:04 mitr: not in the next month is fine. Is it something you might consider in the next _year_? 17:20:14 I want to change the rpmlint task in taskotron to parse the errors better and only fail when certain conditions are met but I don't think that I should be the one deciding what's a real problem and not 17:20:18 mattdm: Consider, yes. Promise, absolutely not. 17:20:21 in any case, merge reviews have been around forever, I'm fine with them staying around for a VFAD, but not sure how much joy that will get us. ;) 17:20:41 We are at fifteen minutes. Vote to continue or take to the list, please. 17:20:57 list 17:21:00 (where it will die) 17:21:08 jwb: :) 17:21:17 This needs a champion to get it anywhere, since we don't currently have one I don't see much point in discussing it further right now 17:21:21 well, or have 10,000 replies. but ok. ;) 17:21:40 I will champion closing the bugs or reassigning to $component all day :) 17:22:17 how many votes did we have on mattdm's proposal? 17:22:32 what was the proposal again? 17:22:32 dgilmore: for VFAD? 17:22:36 Ah, right. Votes on the Jan. VFAD? 17:22:37 +1 17:22:47 +0 17:22:51 thozza: that is the current proposal on the table yes 17:22:58 +1 17:23:06 +1 17:23:07 sure, +1... but I don't think it's going to get us much. :) 17:23:11 sure, +1 if someone wants to do a vfad 17:23:19 Voting for someone else to do something is too easy:) I guess count me as +1 17:23:26 +1 too 17:23:38 and after vfad, we'll deal with what's left with appropriate finality :) 17:24:03 right 17:24:14 works for me, thanks all 17:24:35 #agreed dgilmore and mattdm to talk out of meeting and coordinate time (probably january) for vfad (+6, 1, -0) 17:24:49 We can revisit after that if it isn't magically all done 17:24:59 #topic #1360 Take-over of perl-Locale-PO and perl-HTML-WikiConverter-Markdown 17:25:00 .fesco 1360 17:25:01 sgallagh: #1360 (Take-over of perl-Locale-PO and perl-HTML-WikiConverter-Markdown) – FESCo - https://fedorahosted.org/fesco/ticket/1360 17:25:21 i think this is already resolved 17:25:32 my question here would be what to do with the rest of the 100+ packages maintained by the same person? 17:25:50 Ah, I didn't see the last update 17:26:00 err, 404 packages to be more accurate 17:26:06 kalev: How... fitting 17:26:16 heh 17:26:19 https://admin.fedoraproject.org/pkgdb/packager/iarnell/ 17:26:19 kalev: they will need orphaning 17:27:13 dgilmore: Can you take care of orphaning them and sending an email to devel@ ? 17:27:29 sgallagh: sure 17:27:31 so should we perhaps ask the perl sig about taking the perl ones? or just orphan them and hope for good homes? 17:27:53 Talk to the perl SIG first? They already have commit access to at least some of the packages. 17:27:55 nirik: i think they are all perl ones 17:27:55 I think this needs some special handling given the number of packages 17:27:59 mitr: +1 17:28:02 #action dgilmore to orphan the non-responsive maintainer's other packages and email the devel list. 17:28:25 yeah, there may well be co-maintainers that want to take point of contact there. 17:28:31 #undo 17:28:31 Removing item from minutes: ACTION by sgallagh at 17:28:02 : dgilmore to orphan the non-responsive maintainer's other packages and email the devel list. 17:28:32 Perhaps orphaning them en masse is still the right thing to do, but it’s worth asking. 17:28:52 OK, do we have anyone from PERL SIG on FESCo? 17:29:01 Or willing to act as messenger? 17:29:58 sgallagh: I sit on the same floor with some of them, I can ask tomorrow.... 17:30:16 #action thozza to ask PERL SIG how they want to handle the mass-orphaning 17:30:26 Shall we move on, then? 17:31:02 sure revisit next week 17:31:09 #topic #1361 New Workstation WG liaison 17:31:09 .fesco 1361 17:31:10 sgallagh: #1361 (New Workstation WG liaison) – FESCo - https://fedorahosted.org/fesco/ticket/1361 17:31:28 jwb: Thank you for serving in this role until now. 17:31:34 no problem at all 17:31:44 it's been my pleasure 17:31:51 thanks much jwb 17:32:03 thanks jwb 17:32:09 thank you _very much_ 17:32:11 +1 to Paul 17:32:14 The proposal is for stickster to take over as liaison 17:32:19 thanks jwv 17:32:20 (fwiw, i'm not really going anywhere. just dividing my time more among other groups) 17:32:25 the Workstation WG discussed this privately and was happy with Paul to take this on 17:32:31 jwb even 17:32:33 +1 to paul 17:32:39 +1 to Paul from me too 17:32:46 +1 to Paul 17:32:55 +1 17:32:56 +1 here. 17:33:00 sure, +1 17:33:47 oh, +1 17:34:01 #agreed FESCo welcomes Paul Frields (stickster) as new Workstation WG liaison. (+8, 0, -0) 17:34:10 (sucker) 17:34:10 #topic Next week's chair 17:34:33 I could try doing it next week 17:34:44 #info kalev to chair next week's meeting 17:35:00 I'll be unable to attend next week. I'll be manning the Fedora booth at Usenix LISA. 17:35:12 I will also be unable to attend. 17:36:06 is there a wiki page how to chair fesco meetings? 17:36:08 #info sgallagh and mitr will not be able to make the next meeting 17:36:17 #link https://fedoraproject.org/wiki/FESCo_meeting_process 17:36:21 kalev: yep. 17:36:24 cool, thanks 17:36:45 does the meeting time change next week? 17:36:59 dgilmore: oh good question! 17:37:00 Ooh, good question 17:37:04 ... 17:37:07 jinx 17:37:14 #topic DST and Meeting Time 17:37:33 if it stays the same utc it'll be an hour later in wall clock time, right? 17:37:41 Europe changed the clocks already this weekend 17:37:49 next week we should be back in sync 17:37:52 mattdm: Right, it will become 1400 EST 17:38:14 okay so i get to get up 2 and not 3am 17:38:19 I hate DST. ;( 17:38:25 Does this time cause a conflict with anyone? 17:38:29 no DST here 17:38:34 dgilmore: Stop hanging off the bottom of the Earth, then ;-) 17:39:00 I have a slighter preference for the later slot (makes my lunch not rushed) but can accomodate either 17:39:17 it is nothing like getting up in the middle of the night, either way :) 17:39:20 sgallagh: (TZ=/usr/share/zoneinfo/America/New_York date -d 'dec 1 17:00 utc' says 12:00 EST) 17:39:34 ... did I get that backwards? 17:39:40 i.e. an hour earlier in wall clock it seems to me 17:39:56 ok, so that's less ideal :) 17:40:19 Right, now that I think on it (and look at CET) you're on an hour earlier aren't you 17:40:33 yes 17:40:34 We are this week 17:40:53 dammit. I grew up in Indiana where we didn't have to dealw ith this nonsense 17:41:31 so this week Europe is one hour earlier; if we continue using the same GMT time, next week the US would be an hour earlier as well 17:41:59 right 17:42:13 So that's noon on the US East Coast 17:42:39 which is a hardship for at least two of us :) 17:42:41 * nirik thinks we should just keep it the same UTC and try and ignore DST. And try and avoid this coversation 2x/year by always sticking to the same UTC. ;) 17:42:43 Which is *probably* not conflicting, but still less than ideal. 17:43:08 nirik: we kind of have to have the conversation as membership changes anyway. 17:43:14 proposal: change the meeting time to 18:00 UTC and see next week if it's causing conflicts for anyone 17:43:17 IIRC historically we have been moving UTC to keep mostly the same local time. 17:43:24 nirik: just convince all involved countries to stop the dst nonsense ;) 17:43:26 sgallagh: 12:00 is not so bad :) it was my normal time 17:43:29 right 17:43:31 drago01 +1 17:43:39 drago01: i wish i could 17:43:51 drago01: there was a proposed ballot measure for MA to stop it, but didn't get enough signatures 17:43:51 drago01: I've been trying to convince everyone to just move to UTC. Period. 17:43:57 +1 for drago01 to talk to all countries and convince them to stop the dst nonsense :) 17:44:03 yes good plan. 17:44:13 in the meantime, +1 to kalev 17:44:19 #action drago01 to attempt to propose new international law 17:44:32 lol 17:44:44 +1 kalev 17:44:50 I'm fine with moving it or keeping it, so +0 17:44:50 kalev: +1 I guess. :( 17:45:35 i don't mind... it will be basically the same time as before, so +1 17:45:37 this is a good time for everyone to marvel at the wiki cleverness I put in https://fedoraproject.org/wiki/FESCo_meeting_process so that it shows the date for the current wednesday in the template 17:46:07 mattdm: I actually did notice that yesterday. 17:46:14 cool stuff :) 17:46:16 I wouldn't say "marvel", but it's nifty 17:46:25 :) 17:46:29 I'll take it 17:46:36 (besides, I think Disney lawyers attack whenever you say "marvel" now) 17:47:22 Any other votes? 17:47:27 oh hey look! https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee?rd=FESCo#Meetings 17:47:41 says that switching to 18:00 when dst is off is _already_ our policcy 17:47:54 nobody reads policy 17:48:07 jwb: except occasionally when going to edit the wiki, yes :) 17:48:13 Wait, you guys can read? I guess I should learn. 17:48:33 OK, so this is already policy. Back to open floor, I guess 17:48:47 sgallagh: It has become a policy 2 minutes ago https://fedoraproject.org/w/index.php?title=FESCo_meeting_process&diff=393122&oldid=392107 17:49:24 #topic Open Floor 17:49:29 Any other Open Floor topics? 17:49:34 mitr lol 17:50:06 mitr it as already policy on the _other_ wiki page. 17:50:21 mattdm: Ah, sorry, I didn’t read the link. 17:50:51 there's a new F21 beta RC3 compose being put together tonight, but from what I can tell we should be finally on track with releasing this week 17:51:35 I guess everyone already knew that :) 17:51:48 I sure hope so 17:51:54 Well, the problem is that QA is now back to "hero mode" to validate tonight. 17:52:15 Any help that we can provide would be useful 17:52:32 * sgallagh is already planning to stay up late and work on Server validation when the RC3 lands. 17:52:33 #help Urgent help needed to validate new F21 beta RC3 17:52:48 * sgallagh didn't know that was a zodbot command 17:53:29 sgallagh it puts it in the minutes. I have designs for it to do more, too. 17:53:36 cool 17:54:10 I don't know if FESCo has any incentives available to it, but if we do, this would be a good time to use them 17:56:08 OK, anything else? I'll set the fuse for two minutes 17:56:18 * nirik is going to try and test arm and xfce images tonight. 17:58:28 Thanks for coming everyong 17:58:31 #endmeeting