16:01:56 #startmeeting FESCO (2017-09-15) 16:01:56 Meeting started Fri Sep 15 16:01:56 2017 UTC. The chair is maxamillion. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:56 The meeting name has been set to 'fesco_(2017-09-15)' 16:01:56 #meetingname fesco 16:01:56 The meeting name has been set to 'fesco' 16:01:56 #chair maxamillion dgilmore nirik jforbes jsmith kalev sgallagh bowlofeggs till 16:01:56 Current chairs: bowlofeggs dgilmore jforbes jsmith kalev maxamillion nirik sgallagh till 16:01:59 #topic init process 16:01:59 .hello maxamillion 16:02:00 maxamillion: maxamillion 'Adam Miller' 16:02:01 .hello2 16:02:07 bowlofeggs: bowlofeggs 'Randy Barlow' 16:02:09 .hello2 16:02:10 nirik: Sorry, but you don't exist 16:02:14 haha 16:02:14 ha. :) 16:02:28 .hello stefw 16:02:29 o.O; 16:02:29 stefw: stefw 'Stef Walter' 16:02:54 .hello till 16:02:57 tyll: till 'Till Maas' 16:03:18 I am travelling with bad Internet and will probably not make it till the end 16:03:46 .heelo2 16:03:52 * langdon drawl is showing 16:03:59 .hello2 16:04:00 langdon: langdon 'Langdon White' 16:04:00 * threebean 16:04:24 so we don't have jsmith but he ping'd and said he's voted in all meeting tickets so we don't necessarily need full in-person quorum 16:04:40 I'm here for a few minutes... 16:04:44 maxamillion: I am not certain, but it might be that #chair needs to be done with my IRC nick instead of FAS nick (till) 16:05:07 #chair maxamillion dgilmore nirik jforbes jsmith kalev sgallagh bowlofeggs tyll 16:05:07 Current chairs: bowlofeggs dgilmore jforbes jsmith kalev maxamillion nirik sgallagh till tyll 16:05:14 tyll: you are probably correct :) 16:05:18 I'll update the wiki 16:06:01 maxamillion: thank you 16:06:21 sure thing 16:06:48 sgallagh said he'd be here but will be a few minutes late 16:07:21 jforbes is either at plumbers or traveling home from it and won't be here 16:07:38 kalev-afk: dgilmore: FESCo? :) 16:07:51 I am here now 16:08:05 I pinged dgilmore earlier, but he didn't respond, so I'm going to assume he's AWOL 16:08:55 alright, let's get rolling 16:09:04 #topic Follow Ups 16:09:07 #topic 32 bit UEFI Support 16:09:07 (doesn't have a FESCo Ticket but was brough up last meeting) 16:09:07 .link https://bugzilla.redhat.com/show_bug.cgi?id=1474861 16:09:08 .link https://fedoraproject.org//wiki/Changes/32BitUefiSupport 16:09:39 anyone have an update that's been following this closely? 16:09:53 Last I heard, this was blocked on shim signing. 16:10:01 Which may take months 16:10:05 ugh 16:10:21 so .... what can we do here? or is there really anything for FESCo to do? 16:10:34 * nirik thought it was pretty much done, but also haven't looked closely. 16:11:12 the last comment confirms we are waiting on the signing 16:11:16 right 16:11:32 so basically the install image won't work on i686 without signing ... how do we handle that? has that ever happened? 16:11:42 it sounds like pjones is proposing letting it wait until after GA 16:11:49 which might be the same as delaying it until F28? 16:12:08 if it lands after GA, what's the point? 16:12:26 he did note that "it should happen in the next week or so" 16:12:32 i686 is not a required for release 16:12:36 I assume release criteria is "install image works" 16:12:44 This doesn't block i686 16:12:48 alright 16:12:51 uefi 32 bit won't work. ;) 16:12:56 eh, meh 16:12:57 It blocks UEFI32 16:13:01 so nothing to do here for FESCo? 16:13:06 he makes it sound like ia32 is the arch that gets blocked 16:13:07 Seems like 16:13:09 cool, moving on 16:13:10 #topic #1737 Proposal: i686 SIG needs to be functional by F27 16:13:10 .fesco 1737 16:13:11 https://pagure.io/fesco/issue/1737 16:13:13 maxamillion: Issue #1737: Proposal: i686 SIG needs to be functional by F27 release date or we drop i686 kernel from F28 - fesco - Pagure - https://pagure.io/fesco/issue/1737 16:13:38 I was confused here -- didn't this get resolved last week? 16:13:38 so we have criteria that we asked for 16:13:48 Sorry I am late, at plumbers 16:13:54 jforbes: hey, welcome 16:13:55 Yes, this was approved last week 16:13:58 Gotta run... 16:14:09 jforbes: I just figured you'd be out this week 16:14:25 the criteria was approved, but was the ticket finalized? I wasn't clear on that so I put it on the agenda 16:14:55 i had been under the impression that we'd give them some unknown amount of time to achieve the proposed criteria 16:15:03 Well, the next part of it, is they need to meet that criteria through the F27 release cycle 16:15:10 I think we were waiting to hear their response on our requested changes 16:15:11 F27 release date, i guess that's not "unknown" 16:15:18 Sounds like they're fine with it 16:15:21 sgallagh: they agreed to those changes 16:15:30 Yes 16:15:38 yeah, so i think we should keep this open and discuss closer to F27 release date 16:15:53 alright, do we want to set a date to revisit this to make sure that the SIG is functional based on the criteria? 16:16:12 First meeting after Final Freeze? 16:16:17 Yes, F27 release date 16:16:35 yeah i like first after final freeze 16:16:48 I think we should give them the full cycle, so first meeting after actual release 16:16:48 that way we can give them feedback if we think they are in danger 16:16:56 That offers us the chance to drop it from the webpage if needed 16:16:56 Oh, that makes sense 16:17:05 #proposal Revisit i686 SIG criteria has been met at first FESCo meeting after Final Freeze 16:17:09 * maxamillion +1 16:17:12 +1 16:17:15 +1 16:17:16 +1 16:17:17 sgallagh: it has nothing to do with the F27 release at all 16:17:24 This is all about the F28 cycle 16:17:38 +1 16:17:44 jforbes: sorry, you are correct 16:17:58 +1 to revist and check critera 16:18:06 #agreed Revisit i686 SIG criteria has been met at first FESCo meeting after Final Freeze (+1:6, -1:0, +0:0) 16:18:14 #topic #1760 F27 approved Changes not in MODIFIED status (considered as not testable) 16:18:17 .fesco 1760 16:18:18 maxamillion: Issue #1760: F27 approved Changes not in MODIFIED status (considered as not testable) - fesco - Pagure - https://pagure.io/fesco/issue/1760 16:18:20 https://pagure.io/fesco/issue/1760 16:19:25 https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&classification=Fedora&list_id=7863248&product=Fedora&query_format=advanced&status_whiteboard=ChangeAcceptedF27&status_whiteboard_type=anywordssubstr&version=27 16:19:27 there has been a lot of activity related to the bodhi/modularity stuff this week 16:19:30 (sorry thats ugly) 16:19:36 nirik: it works though :) 16:20:06 * langdon still working on bzs to track open issues for my change 16:20:16 3 of them are modularity related. one flatpacks. one debuginfo 16:20:55 shall we start with modularity? 16:21:00 * threebean nods 16:21:05 however... the issues are all created in the modularity repo: https://pagure.io/modularity/issues but not all are required 16:21:54 the debuginfo one is done IMHO... flatpack we agreed could be done whenever it's done (it's not tied to anything else) 16:22:06 +1 16:22:39 the current proposal from the council (is it approved?) as i understand it is that modular server GA will be released about a month after f27 GA, but that the modular server beta should be released together with the F27 beta 16:22:58 i'm not sure if the council voted on that proposal, or if i got it correct either :) 16:23:08 i believe it is approved.. or mattdm is treating it that way :) 16:23:17 * langdon digs for ticket 16:23:29 It required lazy consensus by Go/No-Go 16:23:31 https://pagure.io/Fedora-Council/tickets/issue/141 16:23:35 So I think that marks it approved 16:23:49 so is this going to be Boltron F27 Edition or is this an actual release deliverable that's not going out with GA? 16:23:55 * nirik had not heard the second part of that 16:24:03 actual release 16:24:16 but, not blocking for workstation or cloud 16:24:30 ... 16:24:39 There's still an open question about whether we will ALSO ship the traditional version (and when). 16:24:40 yeah, I'm not a fan of that 16:24:45 That needs to be discussed by the Server SIG 16:25:18 the need to deliver the beta at the same time as the rest of the f27 cycle does raise a bodhi alarm bell again 16:25:18 maxamillion: Council decreed it; now FESCo has to figure out "how" 16:25:25 Also, they still want the infra/Bodhi stuff ready at Beta, which means that bowlofeggs and threebean still need to make that part work by beta release 16:25:27 So we need more time, but we still expect to ship it with beta? 16:25:33 nirik: No 16:25:38 puiterwijk: i am not sure that part is true 16:25:43 we were discussing earlier.. 16:25:48 langdon: that's how mattdm I think told it the other day 16:25:53 sgallagh: wow ... 16:25:53 The proposal is that Modular will ship its Beta around the time of F27 FINAL 16:26:01 yeah.. we have been going back and forth 16:26:12 sgallagh: oh that wasn't my understanding 16:26:21 sgallagh: ah... that makes much more sense to me. 16:26:32 sgallagh: i asked abotu this during the council meeting, and i interpreted the answer to be that they would share a beta date. possible that i misunderstood... 16:26:46 bowlofeggs: no.. think a month later 16:26:47 but, if that is correct that would assuage my fears 16:26:50 OK, I was pretty sure that's how I understood it 16:26:53 but we will pull it in if we can 16:27:07 Now you have me questioning myself 16:27:09 did they write it down somewhere? 16:27:12 ok that makes me (and probably threebean) feel better (as bodhi person :)) 16:27:21 sgallagh: in that case, the rules don't matter and the Fedora Release is meaningless vocabulary, the "how" is just "throw it over the fence when it's ready because words don't mean anything anymore" 16:27:30 so.. c&w ship beta next thurs, freeze opens, new bodhi drops, s ships beta, c&w ship ga, s ships ga 16:27:51 maxamillion: i lol'd.. sorry 16:28:06 maxamillion: I feel tempted to reply to that entirely with emoji... but I won't 16:28:14 sgallagh: you totally should have :D 16:28:27 we have discussed for a long time that the editions didn't have to all release together 16:28:40 and matt kinda thinks it might even get more press if it was split 16:28:53 langdon: so, due to the way modularity works, we don't need to freeze anything right? modulemd will decide what exact packages are used... 16:28:59 and... given the way the week is going.. modular server may ship before c&w ;) 16:29:24 nirik: right.. but.. let's get that from experience before we change any policies 16:29:26 the council ticket does have a comment suggesting that feedback from releng is needed to confirm that they can do this staggered release 16:29:36 and i don't see a response from releng 16:29:51 bowlofeggs: yeah.. i talked to dgilmore about it yesterday.. there is some work but it should be "possible" 16:29:56 (I'd be more concerned about websites having trouble with this in their workflow than releng.) 16:30:00 also qa... it needs testing and signed off on. I assume using the existing release critera as much as makes sense. 16:30:02 we need them to "officially" weigh in though 16:30:38 nirik: i also have on my list of to dos to update the criteria and images (blanking on the real name for that) 16:30:55 mboddu: ping - you available? 16:31:09 also, the council ticket asks for a schedule. We should actually make one... not "about a month, might ship before xyz, who knows" :) 16:31:21 agreed 16:31:27 maxamillion: see https://pagure.io/modularity/issue/60 for my intepretation of dgilmore's remarks 16:31:30 i think we should get formal feedback from QA and releng too 16:31:36 I have a schedule proposal, we ship on GA date or slip for Fedora 28 16:31:40 >.> 16:32:22 maxamillion: During the council meeting, an Official Voice of our Sponsor asked politely that we not slip it out six months. 16:32:23 i will point out.. this is somewhat moot as we dont have a beta for traditional either yet 16:32:24 langdon: the mirrormanager stuff is basically a black box to me, it's something I should really know better but don't (yet) 16:32:52 maxamillion: i hear ya.. but I am frightened of learning any more than i already do 16:33:53 maxamillion: it seems to me like it would be a council decision about whether it's ok to release staggered, more than a fesco decision. i'm not 100% sure on that, but that's my impression? 16:34:14 bowlofeggs: oh yeah, it is the Council's decision ... I just don't agree with it 16:34:18 haha yeah 16:34:28 which is fine, I don't have to 16:34:29 * langdon thinks he knows who will be showing up for the next council election ;) 16:34:31 I'll stop being snarky 16:34:47 i also feel like waiting until f28 would do a lot of good (for modularity too - more time to bake and test the bodhi stuff, etc.) 16:34:53 hahaha 16:35:08 so i guess our job is to make sure it can technically be done 16:35:14 bowlofeggs: we could wait for f35 too.. it would be WAY better then 16:35:14 It wouldn't be the first time we have had a new release of some sort that shipped after standard. We have done it with alternate arches, we did it with AWS images, etc when first introduced. 16:35:19 proposal: ask for formal ack from qa/releng/websites about this plan, write and approve a actual schedule with dates, make sure modular server passes release testing at any milestones. 16:35:35 nirik: +1 16:35:46 nirik: +1 16:36:05 i have a stupid question.. with the no-go yesterday, what has changed about the fedora-release schedule? anything? 16:36:09 langdon: well that's a bit of a slippery slope argument :) but, i'm happy to stay on task and figure out how we can do this staggered release. i see no problems with it other than needing formal feedback from releng and QA 16:36:14 +1 16:36:16 note that november has thanksgiving holiday in the us at the end... and infra has a big week of outages in early december. 16:36:20 * langdon thinking about what he would model that plan on 16:36:25 +1 nirik 16:36:25 langdon: The schedule had a slip built-in 16:36:30 So the rest of the schedule is currently unchanged 16:36:33 langdon: so far the GA schedule is not affected 16:36:38 sgallagh: yeah.. so it triggered the rain date? 16:36:46 yep 16:36:49 i thought that would be a "decision" not an "automatic" 16:36:49 yeah the beta rain date 16:36:50 langdon: Only the Beta rain date 16:37:03 right ok.. just checking cause i felt like a missed something 16:37:13 "the rain date" ? 16:37:37 maxamillion: yeah... matt put in a rain date for beta and release in case there were slips 16:37:40 maxamillion: the schedule had an alternate beta release date, in case this week was a no-go on the beta 16:37:44 in the official schedule 16:37:46 maxamillion: we planned target and rain dates for beta and final 16:37:49 https://fedoraproject.org/wiki/Releases/27/Schedule 16:38:03 * langdon notes this is the first time 16:38:07 langdon: I'm not familiar with that term though, I was hoping someone could define it for me 16:38:13 ohhh 16:38:18 it's a sports thing I fear 16:38:26 you have an outdoor party.. you have a backup date in case it rains 16:38:26 not "what is the rain date" ... "what is a rain date" 16:38:36 langdon: ... 16:38:38 "A second date scheduled for an outdoor event in case rain forces cancellation of the first date." 16:38:38 langdon: k, thanks 16:38:52 and.. no sportball at all ;) 16:38:56 we really should stop keeping our datacenter servers outside... 16:38:59 particularly used for outdoor weddings 16:39:01 rain == blocker bugs. ;) 16:39:18 i thought they were hailstones 16:39:31 huh, I thought it was games... but ok. :) 16:39:40 alright 16:39:43 i think we have 5 votes on nirik's proposal so far 16:39:53 so we're +4 on nirik's porposal 16:39:59 nirik: most sportball plays through the rain.. unless lightning 16:40:01 oh wait, nirik is +1 too? 16:40:11 * maxamillion doesn't like to assume even though it's likely safe 16:40:15 i presume he is, since he proposed it :) 16:40:30 sure, +1 16:40:59 shall we file a fesco ticket to track all this? 16:40:59 alright ... did we lose tyll? 16:41:25 nirik: seems like a good idea to me 16:41:50 I'm going to assume we've lost tyll, it's been a while since he spoke 16:41:52 #agreed proposal: ask for formal ack from qa/releng/websites about this plan, write and approve a actual schedule with dates, make sure modular server passes release testing at any milestones. (+1:5, -1:0, +0:0) 16:42:21 yeah tyll said he was on a flaky internet connection and would likely have trouble 16:42:31 so no answer is not a +0 automatically? 16:42:45 should we write the schedule with dates now? 16:42:49 * langdon just curious.. but recognizes busy 16:42:54 langdon: no, it's presumed a non-vote ... a +0 is a vote that can be casted 16:43:16 We should someday define that 16:43:19 langdon: a FESCo member can literally say +0 to a proposal meaning they are indifferent and do not want to sway a vote either direction 16:43:19 bowlofeggs: no.. i would hope not.. i would think i would do it offline... and bring it back 16:43:34 maxamillion: gotcha .. null vs 0 ;) 16:43:38 langdon: bingo 16:43:57 bowlofeggs: probably 16:44:17 I hate to chew up time in a meeting that's already going to run long but I don't know when we'll do it otherwise 16:44:36 i'm happy to let langdon do it :) 16:44:37 maxamillion: did you disagree w/ my idea? 16:44:55 langdon: wait, which idea? 16:44:58 cause i think we need to talk to releng, qe, etc 16:45:05 langdon: I think he was agreeing with you 16:45:07 * langdon can't find it :) 16:45:08 And justifying it 16:45:26 bowlofeggs: no.. i would hope not.. i would think i would do it offline... and bring it back 16:45:32 langdon: ah ok 16:45:34 alright 16:45:42 I''m ok with langdon making a schedule... keeping in mind all the stakeholders 16:45:51 i just don't think all of the constituents are here 16:45:58 #info langdon will sync with stakeholders to create a schedule proposal 16:46:09 #topic #1773 F27 Changes not in ON_QA status (<100% completed) 16:46:09 .fesco 1773 16:46:09 https://pagure.io/fesco/issue/1773 16:46:09 or are but only have half their brain watching this 16:46:11 moving on 16:46:13 maxamillion: Issue #1773: F27 Changes not in ON_QA status (<100% completed) - fesco - Pagure - https://pagure.io/fesco/issue/1773 16:46:29 Idea: make sure to discuss that schedule proposal next meeting, to make sure it's not closer to Beta or something? 16:46:45 puiterwijk: +1 16:46:46 yes 16:46:48 (and yes, I'm not in fesco. Just thinking of people I have to work with) 16:46:48 yep. 16:46:49 puiterwijk: I'll put it in the ticket 16:46:55 and.. i like nirik's ticket idea 16:47:01 I had questions for fesco about bodhi. I'll hold them until Open Floor (if that's at the end). 16:47:03 Definitely, the schedule must be final by next meeting 16:47:04 shall I file a ticket? 16:47:38 nirik: oh, separate ticket? I was just going to comment on the existing ticket 16:47:54 alright 16:48:00 well, the existing on is just the 'f27 changes not in on_qa' 16:48:03 i think a separate ticket that focuses jsut on the schedule would be nice 16:48:06 which isn''t very nice. 16:48:08 nirik: right 16:48:12 nirik: +1 to new ticket 16:48:15 i think it may be complicated 16:48:16 * nirik can file it. 16:48:19 hence new ticket 16:48:51 nirik: thanks! 16:49:07 #info nirik to file new FESCo ticket to track the remaining modularity TODO items 16:49:20 alright, current topic is https://pagure.io/fesco/issue/1773 16:49:37 it was voted last week to defer to this week 16:49:55 32-bit UEFI support we already addressed 16:50:15 the bodhi one basically == the modular server one 16:50:20 Bodhi Non-RPM Artifacts was previously addressed iirc 16:50:28 or, it's so closely related we should defer it too 16:50:32 imo 16:50:38 modular release and modular server were previous one too 16:50:48 No More Alphas is done, isn't it? 16:50:56 we certainly didn't make an alpha :) 16:51:02 maxamillion: forgive me, I just joined (late), how did we address it? 16:51:05 or a beta! :) 16:51:08 haha 16:51:17 * sgallagh snickers 16:51:25 pjones: we saw your comments and basically said "we're waiting on signing, nothing for us to do here" 16:51:28 cool 16:51:35 thanks. 16:52:26 and for flatpaks, we decided to defer to F28 (but we can add it whenever we want before F28), right? 16:53:43 I'm not sure what else needs to be done for the Drop 256term.sh thing, it seems like the work is done 16:55:22 the golang 1.9 is done too it seems (though, I'm not sure about the golang packaging guidelines) 16:55:35 and I thought we voted against the TRIM pass down thing 16:56:10 yeah the 256term.sh is ON_QA, so no action needed from us on this ticket 16:56:27 I think glibc is done too 16:57:40 maxamillion: do we have a ticket where the vote against TRIM is documented? 16:57:53 so what ones are actually left to deal with? 16:58:11 in bz it looks like the opposite: https://bugzilla.redhat.com/show_bug.cgi?id=1421596 16:58:27 "ChangeAcceptedF27" 16:59:37 bowlofeggs: trying to find it 16:59:40 but it looks like it missed f26 .. so maybe that is what you are remembering? 16:59:42 * nirik finishes filing https://pagure.io/fesco/issue/1775 on the modular server stuff. 16:59:46 langdon: ahhh ok 16:59:54 i see two that are not ON_QA: https://bugzilla.redhat.com/show_bug.cgi?id=1474910 and https://bugzilla.redhat.com/show_bug.cgi?id=1474902 16:59:58 langdon: maybe I'm thinking of an old deferall 17:00:06 woah! nirik! 17:00:16 nirik++ 17:00:16 langdon: Karma for kevin changed to 22 (for the f26 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:01:10 nirik++ 17:01:11 maxamillion: Karma for kevin changed to 23 (for the f26 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:01:21 nirik++ 17:01:21 sgallagh: Karma for kevin changed to 24 (for the f26 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:01:23 ha. 17:01:27 nom nom nom. 17:01:53 nirik++ indeed :) 17:01:55 anyhow, glibc is done... at least it's a 2.26.90 version 17:02:27 nirik: +1 17:02:48 so should we move that ticket to ON_QA, even though there's no response? 17:02:54 anyone know what's up with Host and Platform? 17:03:18 Thats part of the modular stuff right? 17:03:19 along with modular seerver 17:03:41 but it is suffering the same issues and more as traditional.. shim, binutils, etc 17:03:54 now an issue with pdc not having the correct info 17:04:06 and some fun with ... something.. 17:04:17 lorax 17:04:22 totally blanked 17:04:26 so this would go along with f27 modular server? 17:04:30 right 17:04:36 * threebean nods 17:04:52 so yeah, not much to do. I guess we could move it to ON_QA... 17:04:53 so we can allow it to stay MODIFIED, imo 17:05:45 * langdon isn't sure if you are asking him.. cause he doesn't know 17:05:47 i like MODIFIED since it's not really ready for testing yet, but with the new schedule that's also ok too. we just have to rememebr to come back and check on it later 17:05:56 how's this sound to everyone? https://pagure.io/fesco/issue/1773#comment-465932 17:06:01 * nirik nods. thats fine. 17:06:25 ah, I missed the TRIM down thing 17:06:49 maxamillion: +1 17:07:23 for the record, i don't like the "deferred" language 17:08:02 langdon: what would make you feel warm and fuzzy inside? 17:08:54 on alternate release track? 17:08:59 alright, will update 17:09:02 well "deferred" has specific meaning in this context meaning "it is going to f28".. i don't want to indicate that.. so i would prefer something like "Moved to independent Fedora Server Release" or soemthing 17:09:15 langdon: yeah, well "release" used to have a specific meaning ... but here we are 17:09:18 anyways 17:09:19 * langdon typing slowly today 17:09:29 maxamillion: your snark is on point today ;) 17:10:33 haha 17:10:38 langdon: <3 17:11:33 langdon: https://pagure.io/fesco/issue/1773#comment-465932 17:11:50 LGTM 17:12:01 thanks! 17:12:31 +1 17:12:38 +1 17:13:31 should we consider tyll and jsmith's comments to be +1's on maxamillion's comment? we could ask for them to just +1 again on his comment... 17:13:50 because we didn't exactly do what they said, quite, due to the schedule delay thing 17:15:03 I'm not really sure anything needs +1s here, it's mostly just status updates 17:15:24 #info Status updates to the "not ON_QA" items can be found here: https://pagure.io/fesco/issue/1773#comment-465932 17:15:41 moving on 17:15:42 #topic #1770 Allow PRs for non-packagers 17:15:42 .fesco 1770 17:15:43 https://pagure.io/fesco/issue/1770 17:15:44 maxamillion: Issue #1770: Allow PRs for non-packagers - fesco - Pagure - https://pagure.io/fesco/issue/1770 17:16:07 nothing really to discuss here. 17:16:21 it's not currently possible, we will look at making it so. 17:17:16 If the FESCo agrees with "we just tell what we'd like, we don't dictate the timeline", then my concerns are resolved. 17:18:09 puiterwijk: While I won't *dictate* a timeline, would "within the next year" be realistic? 17:18:22 sgallagh: yes, that would be realistic 17:18:25 I would think so yes 17:18:27 I'm good with that 17:18:30 me too 17:18:32 Probably "the month after F27 release" would be realistic 17:18:42 so ... "by Fedora 28 GA" ? 17:18:43 just needs work... along with all the other work. ;) 17:18:46 The problem is mostly that infra is currently very busy with all things F27 17:18:56 i saw the ticket as being more about policy 17:18:57 maxamillion: if there's no major things planned for F28 GA, yes. 17:19:05 like, would fesco be ok with the idea of other people making PRs 17:19:14 bowlofeggs: oh, rgr 17:19:14 yeah 17:19:16 that's fair 17:19:17 but i didn' tsee it as fesco dictating that infra must do this right away 17:19:21 Also, I would like to point out that the title of the ticket is wrong, evne though that might be seen as a nitpick, but it does point out there's workarounds 17:19:32 bowlofeggs: That was my view exactly 17:20:11 yeah, remote prs work fine (now) 17:20:15 alright, so anything specific here? a proposal of sorts or a refinement of wording? 17:20:16 As in my first comment, non-packagers *can* make PRs. They just can't push to their forks on pkgs, but there's remote PRs 17:20:39 * langdon goes afk for a bit.. but will continue to lurk when back 17:20:49 IMHO we should just close in favor of an infra ticket to implement. 17:20:56 nirik: +1 17:20:58 (+1) 17:21:20 +1 17:22:13 +1 17:22:16 nirik: +1 17:22:42 #agreed Close ticket in favor of an Infra Ticket to implement (+1:5, -1:0, +0:0) 17:22:54 #topic New Business 17:22:55 #topic #1767 F28 Self Contained Changes 17:22:55 .fesco 1767 17:22:55 https://pagure.io/fesco/issue/1767 17:22:57 maxamillion: Issue #1767: F28 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1767 17:24:18 +1 to the MinGW MiniDebugInfo 17:24:32 the Packaging Rust one depends on RelEng tools so I'm not certain we can really vote on that until we can properly produce that content 17:24:41 +1 to MinGW MiniDebugInfo 17:25:25 do we need to wait for the releng ticket to get feedback? https://pagure.io/releng/issue/7005 17:25:42 +1 MinGW 17:25:51 we can revisit if there's any problem there. 17:26:00 maxamillion: we already decided the rust one. ;) 17:26:04 i'm a +1 then 17:26:47 nirik: oh, derp ... we sure did 17:26:59 sgallagh: what say you, sir? 17:27:17 (would it be good for these changes tickets to be 1 ticket per change, rather than 1 ticket with a list of changes?) 17:27:50 maxamillion: Sorry, what's the question? 17:28:01 sgallagh: MinGW MiniDebugInfo self contained change 17:28:04 sgallagh: https://pagure.io/releng/issue/7005 17:28:07 sgallagh: https://fedoraproject.org/wiki/Changes/MingwMiniDebugInfo 17:28:16 (second link, sorry) 17:28:19 +1 17:28:41 #agreed F28 Self Contained Changes: MinGW MiniDebugInfo (+1:6, -1:0, +0:0) (including jsmith's in-ticket +1) 17:28:55 #topic #1774 Treat Developer-only Stream for Fedora Atomic Host as non-Released Fedora artifacts 17:28:58 .fesco 1774 17:28:59 maxamillion: Issue #1774: Treat Developer-only Stream for Fedora Atomic Host as non-Released Fedora artifacts - fesco - Pagure - https://pagure.io/fesco/issue/1774 17:29:01 https://pagure.io/fesco/issue/1774 17:29:18 * stefw has added a "Why?" comment down below on that issue 17:29:22 as it was missing from the description 17:29:25 maxamillion: i think your comment on that ticket was from a different paste buffer 17:29:52 bowlofeggs: it sure is 17:29:55 tmux vs wayland 17:30:14 bowlofeggs: thanks 17:30:17 bowlofeggs: fixed 17:30:25 lgtm :) 17:31:40 my only concern with this is really the potential load on the systems serving the non-mirrored content but I think that's the same problem with all ostree stuff right now 17:31:51 * threebean nods 17:32:18 the total size of the users of the development stream of fedora atomic will likely remain on the small side. 17:32:27 could/should *.fedorainfracloud.org be used for this? 17:33:13 bowlofeggs: it has a different "SLA" so I'm not sure I'd put real production services/content there 17:33:27 true 17:34:05 otoh, this content has a different "SLA" also. :) 17:34:09 hum... 17:34:13 i don't see an issue with this (other than potential infra load), since it's not intended to be user facing 17:34:18 should we ask for infra feedback? 17:34:44 well, some of the usual fedora requirements are legal... ie, have to have source for x time, etc 17:35:42 nirik: could the content here be considered "like scratch builds"? 17:35:43 otherwise I am fine with it. so, perhaps a looksee by legal might be good to get... 17:35:50 nirik: the sources are just srpms like everything else, this is just rolling them into ostrees for distribution, is there separate legal concerns? 17:35:53 it could be sure. 17:36:24 threebean: well, with scratch builds, we still keep the srpms for the time we keep the scratch builds 17:36:54 maxamillion: sure, but do we keep those srpms? the right amount of time? 17:36:59 Whereas with these development ostrees, we don't have all of the sources recorded as stringent as we do for scratch builds. So that comparison is moot 17:37:20 it may not be a problem... but worth checking into 17:37:37 proposal: ask for feedback from infra (re resources/load) and legal (re: keeping srpms that the ostrees were built from) 17:38:13 if it's the only problem with this ... i can work out having the CI/CD pipeline include the srpms along with the artifacts 17:38:20 nirik: yeah, I see your point ... it depends :/ 17:38:36 fwiw, the src.rpm files are already included along with the artifacts 17:38:39 http://artifacts.ci.centos.org/artifacts/fedora-atomic/f26/ 17:38:44 stefw: well, may not be needed. Dunno, but spot/legal could say 17:38:50 stefw: it's also a matter of retention and capacity planning with Infra ... Fedora Infra is always short on storage 17:38:53 and that might be enough there too. 17:39:00 nirik: +1 17:39:02 maxamillion, indeed, hence the interest in keeping the usage low 17:39:05 stefw: +1 17:39:08 with low retention 17:39:15 alright, I'm +1 to bowlofeggs' proposal 17:39:17 and low number of targetted users 17:39:34 I have to shut down for a bit, switching rooms 17:39:34 I don't think there will be much problem from infra... we do need to make a non mirrored space, but we have been talking about that a while. 17:39:42 stefw: do you have any idea on the size? 17:39:46 nirik: ah ok 17:40:16 it would likely be about 10G per day ... which we could keep for a few days 17:40:41 so think around 50G 17:40:52 ok, no problem then 17:41:02 * stefw gets those numbers from the rate of change for affected packages 17:41:04 that 10G per day made me think of "we will raise your planet's temperature by a million degrees… a day, for five days" for some reason... 17:41:24 heh heh 17:41:49 +1 to the proposal 17:43:11 +1 17:44:00 i think that's +4? (me, maxamillion, nirik, and sgallagh) 17:44:12 yeah, and jforbes is in transit to a new location 17:44:22 we don't have quorum until/unless he comes back 17:44:33 we also have +1s in the ticket, but not on this exact proposal 17:44:34 maxamillion, jsmith also gave a +1 in 1774 17:45:12 oh right 17:45:39 we could just document the proposal with 4 +1's and ask for their comment 17:45:46 i bet they'd +1 17:45:55 since they +1's to something more permissive 17:45:58 right 17:46:11 I'm not sure what is the appropriate course of action on this one 17:46:28 we could wait for jforbes to come back too 17:46:56 I'd want to set a time limit on how long to wait though... I still haven't had lunch :) 17:47:30 i think soliciting votes in the ticket and moving on should be ok 17:47:36 sounds good 17:47:39 i'm sure we'll get the vote 17:48:57 #topic Next week's chair 17:49:00 who's up? 17:49:12 I can do it. I said I would the other week and bailed. 17:49:39 #info nirik to chair next weeks FESCo meeting (2017-09-22) 17:49:46 #topic Open Floor 17:49:53 woot! we made it to open floor 17:50:01 threebean: you had something irrc 17:50:02 iirc* 17:50:08 yes! 17:50:09 maxamillion: re https://pagure.io/fesco/issue/1774 - i am bowlofeggs in FAS :) 17:50:12 bodhi - and modules. 17:50:22 I had one question on modular server... are we making the legacy one for f27 or not? or who decides it? 17:50:42 last week, there was an urgency to get modularized bodhi into prod before the beta freeze was up. 17:50:46 bowlofeggs: fixed 17:51:01 nirik: The release-blocking deliverables have previously been delegated to the WGs 17:51:14 So I assume we'd discuss it on Tuesday at the Server SIG meeting 17:51:23 sgallagh: ok, fine with me. 17:51:24 threebean: so, about that, I've heard two different answers in two days, but today I heard that the modular server beta is also probably going to be delayed, and we'd need bodhi ready by that beta 17:51:31 it seems to me that with the de-coupled schedules now, I don't need to focus on getting that in place before beta freeze is up. I can wait until beta freeze is up, and then deploy bodhi with modular support. 17:51:35 am I reading the situation right? 17:51:35 nirik: the plan is to have both in either scenario.. just one will be "fedora server" and the other will be next to it with "if the real one doesn't meet your needs use this" 17:52:00 langdon: Let's discuss that on Tuesday. (I disagree) 17:52:01 threebean: basically, wait for langdon's schedule, as it should tell you when the modular server beta is going to be due. And by then, they want the bodhi stuff live 17:52:03 i am also confused/concerned about the bodhi and modularity schedule :) 17:52:06 sgallagh: ok 17:52:19 sgallagh: thats the *current* plan .. subject to change on tues :) 17:52:35 * nirik is fine with that too, just needs communicated. 17:52:37 ok. puiterwijk a question we need to explore, then, is what happens to the infrastructure freeze schedule if the edition schedules are now decoupled? 17:53:11 threebean: nirik asked langdon whether infra needed to be frozen for modular stuff (given that it's all defined by modulemd's), but I didn't see an answer 17:53:16 it concerns me that bowlofeggs as the primary maintainer of bodhi, is concerned out it :) 17:53:16 yea, what does a freeze even mean in the context of overlapping schedules? wouldn't we just be in a freeze for a long time since either schedule could cause a freeze? 17:53:41 about it * 17:53:46 threebean: "it all is defined" == "the exact commits of packages are defined by" 17:54:21 yes. but if we take koji down for a week for maintenance, it doesn't matter how well defined the content is :p 17:54:31 the other part of a freeze is gating updates... thats hopefully ok to not freeze since modularity will pick what it uses. but that does not answer the infra side... 17:55:10 did the council take this element into consideration when they decided to allow different schedules? 17:55:20 i don't recall this being discussed there 17:55:42 bowlofeggs: i think it was conviently ignored ;) 17:55:51 right. 17:56:02 sorry all I was afk 17:56:25 I suppose for this we could either freeze again/longer or try and keep everything in a good state and minimize changes. 17:57:02 imho, we should freeze infra for the traditional cycle, but keep it unfrozen (generally) for the modular cycle. the modular cycle is new and so 1) needs flexibility to change/fix quickly and 2) gets the short-straw if other infra changes get in its way. we should revisit such an arrangement for f28, though. 17:57:16 threebean: that seems reasonable to me 17:57:19 threebean: +1 17:57:37 yeah, we completely need to revisit this and see if its going to expand/happen more, or is just a one off 17:57:38 nirik: thoughts on threebean's proposal? 17:57:45 threebean: that sounds reasonable. I'd be really hesitant of freezing infra during the modular time as well, since it'd grind infra to a halt probably 17:57:45 nirik: we just freeze infra forever 17:57:54 haha 17:57:58 dgilmore: vacation!! 17:58:00 yeah i am +1 to threebean too 17:58:09 (in general, actually) 17:58:13 * nirik heads to the beach 17:58:21 bowlofeggs: you mean you're +1 to everything in general? 17:58:23 * sgallagh has a hard stop in two minutes 17:58:35 oh, let we close all tickets with 'sorry, frozen forever' :) 17:58:39 puiterwijk: no i mean i'm a +1 to threebean in general. he's a stand up guy! 17:58:44 seems like its decided.. f26 is the perfect, never changing, version of fedora.. /me beaches too 17:58:51 anyhow, I think threebean's proposal is reasonable. We can discuss it more in infra meeting 17:58:51 I'm +1 to whatever nirik and puiterwijk vote for on the issue, at the end of the day they are left with the pieces 17:59:13 nirik: +1 17:59:19 * bowlofeggs hands nirik and puiterwijk each half of the pieces of his shattered laptop and heads to the beach 17:59:26 ha 17:59:49 bowlofeggs: you sure you want to do that? If you give me the part with the hard drive and it still had some power, I might be able to get your photos! 18:00:01 bowlofeggs: :) 18:00:12 haha 18:00:13 it is just photos of cats he got from reddit 18:00:23 langdon: +1 18:00:23 (we already determined I already have your gpg key, so I don't care about that one) 18:00:26 alright 18:00:36 * nirik thinks we are done :) 18:00:39 is there anything else on this or we good to move on and/or close out? 18:00:39 yeah puiterwijk is my gpg API so i had to give him my key 18:00:49 +1 to closing out 18:01:00 puiterwijk-gpg-signing-as-a-service 18:01:04 langdon: reddit.com/r/aww - my favorite pastime when things are burning 18:01:05 * langdon still has to file a whole mess of bzs :/ 18:01:11 puiterwijk: right? 18:01:17 thanks fesco! 18:01:38 adios 18:01:41 we need the fedora status page to cycle with r/aww/hot 18:01:49 alright, I'm lighting the fuse ... 60 seconds and we're done 18:01:55 langdon: +1 18:02:41 BOOM 18:02:53 bowlofeggs: 8 seconds early :) 18:03:05 hahah 18:03:07 #endmeeting