15:00:08 #startmeeting FESCO (2018-08-27) 15:00:09 Meeting started Mon Aug 27 15:00:08 2018 UTC. 15:00:09 This meeting is logged and archived in a public location. 15:00:09 The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:09 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:09 The meeting name has been set to 'fesco_(2018-08-27)' 15:00:18 #meetingname fesco 15:00:18 The meeting name has been set to 'fesco' 15:00:24 #chair nirik, maxamillion, jsmith, jwb, zbyszek, tyll, sgallagh, contyk, bowlofeggs 15:00:24 Current chairs: bowlofeggs contyk jsmith jwb maxamillion nirik sgallagh tyll zbyszek 15:00:25 .hello2 15:00:26 bowlofeggs: bowlofeggs 'Randy Barlow' 15:00:28 #topic init process 15:00:30 .hello2 15:00:31 .hello2 15:00:31 sgallagh: sgallagh 'Stephen Gallagher' 15:00:33 .hello psabata 15:00:33 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:00:34 .hello2 15:00:36 contyk: psabata 'Petr Šabata' 15:00:39 maxamillion: maxamillion 'Adam Miller' 15:00:45 .hello till 15:00:46 tyll_: till 'Till Maas' 15:01:03 sweet sweet quorum 15:01:15 contyk: it would be great if we could discuss #1970 in the first half hour, since later pingou is gone 15:01:26 .hello2 15:01:27 bcotton: bcotton 'Ben Cotton' 15:01:37 pulling double meeting duty again, but will try 15:01:44 zbyszek: sure 15:02:00 * nirik waves 15:02:04 * pingou is around 15:02:16 #topic #1970 Action needed: Orphan packages will be retired if they remain orphaned for six weeks 15:02:20 .fesco 1970 15:02:21 contyk: Issue #1970: Action needed: Orphan packages will be retired if they remain orphaned for six weeks - fesco - Pagure - https://pagure.io/fesco/issue/1970 15:02:23 https://pagure.io/fesco/issue/1970 15:02:31 ok, let's get started 15:02:36 .hello2 15:02:37 jsmith: jsmith 'Jared Smith' 15:03:07 So... I think we need to implement $subject somehow 15:03:33 But from what I can see, pagure does not export the history of ownership changes, w/o which it's hard to do the orphaning properly. 15:03:45 pingou^ 15:03:50 zbyszek: I suppose the idea is to use datagrepper for the history 15:04:05 zbyszek: or maybe not "the" idea, but at least it is a possibility 15:04:26 note that datagrepper isn't going to perfectly record all messages 15:04:38 so it may work most of the time, but messages can get lost with current fedmsg 15:04:45 the new fedora-messaging library should help with this 15:04:53 Hm, I didn't think about datagrepper 15:05:11 I think we could export this in a json file in the extras/ folder as we do for bugzilla's POC 15:06:02 pingou: actually we do not need the full history, just a reliable timestamp of when the package was orphaned, so maybe the existing json files can just be extended 15:06:36 tyll: we could easily export the namespace/name/last_update fields 15:06:40 I think a full history would be very good too — it's important to be able to see who owned the package when 15:07:08 i agree with zbyszek 15:07:14 bowlofeggs: people seem to put an emphasis on that all the time, but with Ralph's audit toolchain we never once noticed a lost message 15:07:17 would be nice to store the history somehow for sure 15:07:22 pingou: is last_update only about the owner? 15:07:26 maxamillion: i've definitely lost messages 15:07:26 bowlofeggs: in like 2 years 15:07:35 maxamillion: many times with bodhi 15:07:37 tyll: about the change in the projects table 15:07:41 bowlofeggs: in datagrepper? 15:07:43 it's been a real problem several times 15:07:51 maxamillion: no, just with fedmsg in general between bodhi's own nodes 15:07:59 if those can get lost, so can others 15:08:23 rgr 15:08:27 anyways 15:08:53 so re this ticket, is the current state that we basically can't take action due to missing info? 15:09:13 i.e., we don't know how long packages have been orphaned, so dont' know which ones can be retired? 15:09:22 bowlofeggs: yes 15:09:47 bowlofeggs: well, we could can dig it out from datagrepper as tyll says 15:09:51 pingou: is the missing info in pagure's db and just needs to be exposed, or is it not recorded at all? 15:09:52 bowlofeggs: Miro started to record which packages are currently orphaned, so we could retire them in 6 sweeks if they are still orphaned 15:10:01 yeah datagrepper probably does have the info we need here 15:10:07 but just not guaranteed 15:10:22 tyll: yeah that would work too 15:10:25 Before the packages should be retired, there need to be several warning messages, too 15:10:33 (at least there were in the past) 15:10:35 we could orphan the ones where the info is found, it'll probably be almost all 15:10:42 so for our current problem we have a workaround, and we'd like to request a feature from pagure for future? 15:10:50 bowlofeggs: exactly 15:11:14 bowlofeggs: the projects table has a last_updated field 15:11:17 cool. do we need a fesco proposal then, or should we just keep this ticket open and see how things play out? 15:11:21 and the main admin is stored in that table 15:11:45 pingou: is that last_updated any time the project was updated at all though, vs. specifically when a package was assigned to orphan? 15:11:50 * nirik got a phone call, sorry, catching up 15:12:01 bowlofeggs: IMHO it basically needs someone with time to implement this 15:12:01 because if a project is updated after being orphaned, wouldn't that change that time stamp? 15:12:14 it would 15:12:35 but would a project be updated once it's orphaned? 15:12:53 a co-admin might still do things or remove themselve as well 15:12:55 pingou: cool. so that sounds potentially useful, though not precisely the data we want. because yeah, a project would probably not typically be updated while being orphaned 15:13:21 i think knowing the history of people in the package would be more precise 15:13:23 * nirik wonders how many packages we have that are orphaned, but have other admins/commiters 15:13:57 it's possible that those packages are maintained by those people and they dont' even know its orphaned too 15:14:15 nirik: I checked a few and most if not all had others... I believe having inactive co-maintainers is another problem 15:14:17 that might be quite common, yeah 15:14:19 tyll: we should check if that would change the projects table, I'm not sure 15:15:16 maybe step 1 should be to contact the co-maintainers and tell them their projects are orphaned and to please claim them? 15:15:17 perhaps we should reassign all those. 15:15:26 nirik: to whom? 15:15:33 ie, orphan -> first admin or commiter 15:15:36 or we could just pick a random one and promote them to primary contact :) 15:15:51 bowlofeggs: the script to report orphaned pkgs would notify all co-maintainers 15:15:51 or most recent person to touch the package haha 15:15:59 tyll: cool 15:16:06 bowlofeggs: but it needs to be ported to pagure as well IRIC 15:16:08 IIRC 15:16:09 "you touched it last, you're it!" 15:16:15 bowlofeggs: yay for rcm ;) 15:16:20 hahaha 15:16:21 true 15:16:26 bowlofeggs: +1 15:16:29 i think "you touched it last, you own it now" makes more sense than an "orphan" that still has parents 15:16:35 well maybe we only consider those with formal ACLs 15:16:43 isn't that how open source works? "$PERSON touched it last, they are the maintainer" 15:16:48 "most recent person that touched it and is already on the ACL list for it" 15:16:54 maxamillion: lol 15:17:10 https://pagure.io/releng/pull-request/6895 is a PR to update th e script, the problem there was that previously orphan status was per branch, now it is per package 15:17:57 FWIW, there are 3610 projects in rpms/ namespace owned just by orphan, and 4044 where orphan is one of the owners 15:18:21 wow 15:18:25 that's a huge number 15:18:36 but that's not filtered by retirement status, so not very useful ;( 15:18:36 this is a big problem then 15:18:38 But I guess many of them might also be retired already 15:18:45 ah 15:19:23 man the retirement of pkgdb left so many unresolved messes :/ 15:19:42 bowlofeggs: I feel like that's how kernel subsystem maintainership works anyways 15:20:12 tyll: how does #6895 extract the info how long a package has been orphaned? 15:20:48 i won't have any $free_time to help with this stuff for a couple weeks, but i may be able to help in about 3 weeks time 15:21:00 #info https://pagure.io/releng/pull-request/6895 15:21:05 zbyszek: it seems to be using date_modified or date_created 15:21:05 i may be able to petition for some $work_time to help with this stuff before then too 15:21:37 maybe it would help for us to identify specific requirements we'd like the orphaning system to achieve for us? 15:22:19 So, is date_modified enough for this? 15:22:42 pingou: ^ 15:22:46 well, I think we just want to know someone(s) talking care of the packages... but even having a point of contact doesn't ensure that 15:23:12 zbyszek: i think date_modified will probably get us by, though isn't ideal 15:23:15 as a way around and until we have better 15:23:24 most of the time it'll probably be the date we wanted 15:23:41 imo, it's $good_enough_for_now 15:23:50 date_modified seems to have been added for this purpose at least: https://pagure.io/pagure/issue/2412 15:23:52 OK, so it seems we can hobble together a script to do the orphaning. I'll work on this. 15:23:54 but i bet it'll occasionally be incorrect 15:24:21 I'd argue that being occasionally incorrect would actually be a positive 15:24:25 Yeah, some packages will handled later than they should be. But that's better than the other way around. 15:24:40 Every time we hear someone complain about the script, we have confirmation that it's *really* maintained 15:25:05 zbyszek: the pkgs are already orphaned and the script is already there, it just needs to be fixed... 15:25:32 sgallagh: heh 15:25:40 zbyszek: what is also required is to run the script regulary and later to the retirement... however, retiring is easy once the list of pkgs is clear 15:25:54 zbyszek: except... that retirement now needs to happen on multiple branches 15:26:46 Yeah, that's another problem. 15:26:55 zbyszek: thinking more about this, this does not matter, becauset here were multiple reports for each branches in the past as well 15:27:27 Do we block the package in F29+, but not retire it in pagure until F27 and F28 are EOL? 15:27:56 zbyszek: it is not possible to retire pkgs in stable releases 15:28:12 zbyszek: it is only possible for Branched, Rawhide and EPEL 15:28:31 Right, so how we achieve that with src.fp.o? 15:28:53 zbyszek: it may be possible to request the factory 2 team to get that script fixed up, since it probably just fell off their radar. unless you just want to do it yourself. 15:29:03 zbyszek: just call "fedpkg retire" in the appropriate branch, there is also a wrapper in releng git for this to make it easy 15:29:17 bowlofeggs: if that'd be possible, that'd be great. 15:29:46 threebean: any chance factory 2 could finish up the orphan retiring script? 15:30:03 we've been on this issue for 30 minutes, can we either have a proposal soon or punt? 15:30:05 The PR https://pagure.io/releng/pull-request/6895 might be already ready 15:30:28 I do not have much time but I could give it at least a test run 15:30:52 tyll: your last comment in the PR indicates that it still needs work 15:31:14 +1 to wrapping this up 15:31:19 what do we need to decide on today? 15:31:48 zbyszek: I believe this is somehting that is not really going to happen, soon, so for now we can assume that if a pkgs is oprhaned, it is orphaned for all branches and handle it this way 15:32:09 zbyszek: otherwise we need more visibilty for the poc_override GIT repo 15:32:28 I mean this one: https://pagure.io/releng/fedora-scm-requests 15:32:41 bowlofeggs: I hope we can decide on a rough plan needed to get the orphaning happening, with at least some initial action plan 15:33:49 proposal: contact factory 2 to see if they want to finish the script 15:33:57 heh 15:35:20 "factory 2" means threebean? 15:35:44 can we get retirement info from pagure (ie, RFE to provide that info)? 15:35:45 zbyszek: it's a team that threebean is part of 15:35:48 And/or his team, the team that wrote the "factory 2 tools" 15:36:10 nirik: retirement info is in PDC 15:36:24 zbyszek: factory 2 made the changes that involved retiring pkgdb 15:37:09 true, but then you have to cross refrence all the orphans against that... which is not handy for things like 'what orphan packages might I want to take over' 15:37:10 and i assume their goal was to leave us with functional equivalence, so they may be willing to help solve this problme 15:38:19 nirik: I see 15:39:04 OK, and assuming that "factory 2" poeple finish the script, how do we proceed? 15:39:43 Implement the 'reassign-to-comaintainer-who-last-touch-package' proposal? 15:40:33 zbyszek: i personally like that proposal. or alternatively, "contact other maintainers and ask for a volunteer. if no response in n weeks, retire" 15:40:34 then someone needs to run the script and send reports to fedora and epel devel mailing list 15:40:46 I think that would be good to do before any runs of the scripts... but that needs another script. ;) 15:40:52 heh 15:40:53 this should happen weekly and after 6 weeks the first set of pkgs will be retired 15:40:54 so many scripts 15:41:06 bowlofeggs: No kidding... 15:41:27 haha 15:41:32 find_unblock_orphans creates reports to be send to the mailing lists 15:41:36 We don't need to wait 6 weeks yet again. Just notify, and re-assign or retire a week later. 15:42:00 i think i'd be fine with a auto-reassign to make less tasks for ourselves 15:42:14 though that does mean the person you reassigned to might also be non-responsive 15:42:17 but meh? 15:42:18 zbyszek: I think that is something to decide after looking at the affected pkgs ... also the pkgs taht depend on the orphaned pkgs are affected 15:42:33 unless we can fully automate all this stuff 15:42:58 if there was an automated system to do all the e-mailing/retiring that'd be obvs ideal 15:42:58 OK, so proposal: 1. contact factory 2 to see if they want to finish the script, 2. once the script is ready, send info to all co-maintainers and fedora-devel, 3. after a week reassign to one co-maintainer, if no co-maintainers, retire 15:43:11 zbyszek: +1 15:43:25 zbyszek: +1 15:43:56 1 week is a pretty short ramp, but ok... +1 15:44:10 bowlofeggs: basically, it's the kernel, gcc, coreutils, python, perl and then just a massive pile of scripts 15:44:24 zbyszek: +1 15:44:34 how about we start minimal notifications to the devel list right away to make people more aware? 15:44:54 just send the list of orphaned pkgs to $pkg-owner and the devel lists 15:44:54 zbyszek: +1 15:45:12 maxamillion: hahah pretty much true 15:45:15 then it is not much of a surprise once the real report is creatd with all the deps 15:45:19 tyll: that would be great if we can get it... 15:46:01 assuming zbyszek is +1 to his own proposal 15:46:20 bowlofeggs: oh, and javascript ... I keep forgetting (or trying to forget) that javascript is attempting to take over the world 15:46:49 nirik: can't weu se this list? https://github.com/hroncok/fedora-orphaned-packages 15:46:58 #agreed The plan is: 1. contact factory 2 to see if they want to finish the script, 2. once the script is ready, send info to all co-maintainers and fedora-devel, 3. after a week reassign to one co-maintainer, if no co-maintainers, retire (+6, 0, 0) 15:47:12 should we move to the next topic then? 15:47:27 tyll: OK, I'll work with Miro to send the list to fedora-devel quickly 15:48:12 contyk: may I suggest #1935? 15:48:29 zbyszek: that's what I was going to go with :) 15:48:36 #topic #1935 [Security] Remove packages which has a consistent bad security record from the distribution 15:48:38 .fesco 1935 15:48:40 contyk: Issue #1935: [Security] Remove packages which has a consistent bad security record from the distribution. - fesco - Pagure - https://pagure.io/fesco/issue/1935 15:48:42 https://pagure.io/fesco/issue/1935 15:48:45 our favorite 15:48:50 heh 15:48:55 this ticket just doesn't go away! 15:49:58 zbyszek: what do you think of my counter proposal in the ticket? 15:50:03 only change is the date 15:50:22 i was just worried that doing it at branch date would cause risk to the release date (depending on the package) 15:50:36 bowlofeggs: I don't really have an opinion, I'm fine with the earlier date. 15:50:47 We missed F29 anyway 15:50:51 yeah 15:51:01 i'm not opposed to your proposal as written either 15:51:03 i'd +1 either 15:51:04 I'm fine with it, but we need someone(s) to manage it... 15:51:29 nirik: yep, yet another script to be written 15:51:40 we are piling up a lot of responsibilities for ourselves. this would benefit from automation (as would the orphan retiring ticket we just discussed) 15:52:04 bowlofeggs: it would. The problem is that we had automation, but we lost it. 15:52:14 But let's not cry over spilt milk. 15:52:17 since fesco membership can change at elections, it'd be even wiser than usual to make all this stuff automated ☺ 15:52:23 zbyszek: true 15:52:37 Just let's be more careful with setting requirements in the future ;) 15:52:41 haha 15:53:03 do others care about the date and/or have thoughts on the general proposal? 15:53:06 we lost it? when did we have it? :) 15:53:14 I prefer the earlier date. 15:53:17 the proposal: https://pagure.io/fesco/issue/1935#comment-527041 15:53:26 (except that i propose 4 weeks before branching) 15:53:49 proposal: If a CRITICAL or IMPORTANT security issue is currently open against a package, or a security issue of lower severity has been open for at least 6 months, four weeks before the branch point a procedure similar to long-standing FTBFS will be triggered immediately, with 8 weeks of weekly notifications to maintainers and subsequent orphaning and then subsequent removal from distribution. This applies to all packages, not just leaf. 15:53:54 I still think the same as last week -- I wouldn't limit this to critical or important issues 15:54:08 even if it's a low priority, the maintainer should respond in some way 15:54:14 contyk: Reread it 15:54:23 contyk: maybe we can start with CRI/IMP, and see how that goes? 15:54:35 are the FTBFS notifications already happening? 15:54:38 It's basically "lower means six months", critical and important are immediately addressed at branch point 15:54:42 Or am I misreading? 15:55:00 (well, four weeks before branch point, sorry) 15:55:05 tyll: needinfo is set on all ftbfs bugs 15:55:31 alright 15:55:37 tyll: bugs for packages that get built are closed, even if the maintainers don't close the bug. 15:55:41 contyk: +1 15:56:00 sorry, i meant: zbyszek: +1 15:56:06 i meant to +1 the proposal 15:56:10 let's go with this for now then, +1 15:56:27 +1 to the proposal, however I would prefer actual notifications instead of just needinfo 15:56:27 (In case that's not clear, "my" proposal is the same as what bowlofeggs linked to.) 15:57:09 i think needinfo is ok because it also automatically notifies 15:57:15 re-notifies i mean 15:57:16 tyll: I'd prefer the same too. I definitely plan to send out "personal" e-mails before doing something as drastic as orphaning. 15:57:18 +1 here, but we need scripting/automation as noted. ;) 15:57:20 BZ annoys you until you clear it :) 15:58:04 bowlofeggs: but it does not tell taht hte package will be removed 15:58:28 tyll: the text in the needinfo does 15:58:39 I'm rather concerned that this is going to reveal that large parts of our critical path are unmaintained. But I guess it's better to know how bad the situation is. +1 15:58:48 sgallagh: heh, true 15:58:56 sgallagh: we can just put our fingers in our ears if we have to 15:59:20 yay 15:59:52 #agreed If a CRITICAL or IMPORTANT security issue is currently open against a package, or a security issue of lower severity has been open for at least 6 months, four weeks before the branch point a procedure similar to long-standing FTBFS will be triggered immediately, with 8 weeks of weekly notifications to maintainers and subsequent orphaning and then subsequent removal from distribution. This 15:59:53 applies to all packages, not just leaf. (+6, 0, -0) 16:00:01 too long for irc 16:00:25 #agreed applies to all packages, not just leaf. (+6, 0, -0) 16:00:28 let's do it like this 16:00:34 one more topic 16:00:38 haha 16:00:40 #topic #1967 Fedora 29 incomplete changes 16:00:44 .fesco 1967 16:00:45 contyk: Issue #1967: Fedora 29 incomplete changes - fesco - Pagure - https://pagure.io/fesco/issue/1967 16:00:48 https://pagure.io/fesco/issue/1967 16:00:51 zbyszek wins the award for longest proposal since i've been on fesco 16:01:07 do we want the security thumping trigger to be an explicit entry on the schedule? 16:01:18 bcotton: i think that would be helpful 16:01:43 for the current ticket, shall we do them 1x1 like last week? 16:01:51 i'll add to to the F30 schedule 16:01:56 (dont' forget that some got resolved) 16:02:02 bcotton: thanks 16:02:05 bowlofeggs: Might be best. I can't tell which ones are still active easily 16:02:46 we gave silverblue one more week, shall we do that first? 16:02:52 https://pagure.io/pungi-fedora/pull-request/631 16:02:55 let's 16:03:10 https://bugzilla.redhat.com/show_bug.cgi?id=1598405 16:03:20 still no activity 16:03:28 :-/ 16:03:53 there is some work in releng repos landing for this 16:04:00 let's defer it then 16:04:10 #action bowlofeggs will contact mclassen to get an update 16:04:23 +1 to defer 16:04:26 +1 16:04:58 +1 defer 16:05:18 +1 to defer 16:05:20 +1 16:05:49 #agreed Let's defer the "Rename Atomic Workstation to Silverblue" change to F30 (+6, 0, -0) 16:06:23 dstat? 16:06:28 +1 16:06:42 I have mixed feelings about dstat 16:06:53 #undo 16:06:53 Removing item from minutes: AGREED by contyk at 16:05:49 : Let's defer the "Rename Atomic Workstation to Silverblue" change to F30 (+6, 0, -0) 16:06:58 #agreed Let's defer the "Rename Atomic Workstation to Silverblue" change to F30 (+7, 0, -0) 16:07:17 Sorry guys, I need to go in about a minute. 16:07:19 contyk: Wait, what? 16:07:25 dstat says it's MODIFIED 16:07:27 I thought we were deferring the decision by a week' 16:07:37 another week? 16:07:50 yeah i thought we were giving a week too 16:07:53 not deferring to 30 16:07:53 I am -1 to deferring to F30 (today, at least) 16:08:04 alright, apologies for the confusion 16:08:06 #undo 16:08:06 Removing item from minutes: AGREED by contyk at 16:06:58 : Let's defer the "Rename Atomic Workstation to Silverblue" change to F30 (+7, 0, -0) 16:08:07 contyk: Work is in progress (as nirik noted and I have also seen) 16:08:07 yes, just a week, -1 to deferring to F30 16:08:08 right... 16:08:36 everyone was voting for deferring by another week then? 16:08:46 i was 16:08:51 That said, if they don't have things in shape next week, I'll recommend pushing to F30 16:08:52 we can do another proposal to clarify 16:09:03 sgallagh: yeah me too 16:09:19 yeah, I thought we were giving another week 16:09:38 Proposal: Will check on the "Rename Atomic Workstation to Silverblue" change in a week again 16:09:43 hang on, I'm getting a WS rep to join 16:09:55 * stickster is probably not the right person if this is technical, but let's see what's shaking 16:10:05 s/technical/overly \1/ 16:10:19 stickster: Currently, we have no status from WS about whether Silverblue is on track for F29 16:10:29 A quick update on "update festival to 2.5": I went through the sponsorship process for the Change owner, and the Change seems to be on track. 16:10:31 Or if the Change should be deferred to F30 16:10:45 I'm definitely not the right person to answer this. 16:10:49 stickster: also we were wondering if you could lay down a slick bass line for our meeting 16:11:01 *sick 16:11:07 NOW YOU'RE TALKING (either way) 16:11:20 stickster: OK, we're deferring the decision until next week, but I think we will probably vote to bump it to F30 if there's no response by then 16:11:24 * stickster waits to see if mclasen or someone else who knows shows up 16:11:30 So please pester whomever needs pestering 16:11:30 fwiw, looks like infra just pushed a patch related to this 16:12:01 #link https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/V4AMRMWOWIAPZFQTLUBWNDD3FU5OQOZX/ 16:12:17 not sure how meaningful that is to the change itself 16:13:03 * nirik suggests we move on instead of trying to track down things in realtime 16:13:07 mclasen will be joining momentarily 16:13:35 mclasen: FESCo mostly just needs a statement about whether Silverblue is on track for F29 16:13:43 nirik: +1 16:13:52 mclasen: https://bugzilla.redhat.com/show_bug.cgi?id=1614277 16:13:53 Because the requests for update in the Change BZ have gone unanswered 16:14:07 sgallagh: not really prepared for making one... 16:14:07 whoops wrong link 16:14:16 mclasen: https://bugzilla.redhat.com/show_bug.cgi?id=1598405 16:15:18 mclasen: fyi we may want to defer the change to f30 if it's not ready by next week 16:15:33 or at least, the idea has been discussed here (though not voted on) 16:15:53 * mclasen can't push all the things... 16:16:32 mclasen: Mostly we just want to know if you think things will be in place by Beta Freeze (or if you need us to pressure anyone to help move things forward) 16:16:33 mclasen: what needs to be done to finish it? 16:16:58 mclasen: also mostly we just want to see communication regarding the change so we know you still want it to happen 16:17:05 * mclasen points a"scope" 16:17:31 i want it to happen 16:17:31 beta freeze is schedule to start tomorrow, btw: https://fedorapeople.org/groups/schedule/f-29/f-29-key-tasks.html 16:17:50 oof, I thought we had another week. Yikes 16:18:11 oh yeah that's not going to be good if we let this slip a week 16:18:28 should we invoke the contingency plan on this? 16:18:38 * sgallagh doesn't really want to 16:19:03 the contingency deadline in the change page does say "beta" 16:19:08 the one user-visible change here is the name of the iso 16:19:10 does that mean beta release, or beta freeze? 16:19:33 bowlofeggs: Well, Beta Freeze means that the features are present and only blockers and FE's are allowed 16:19:42 right 16:19:49 So realistically it means that we need it today :( 16:20:05 mclasen: do you think you can get the name of the ISO in place today? 16:20:12 no idea 16:20:21 * mclasen not very helpful here 16:20:46 no activity on the releng ticket either https://pagure.io/releng/issue/7579 16:21:21 dustymabe and walters have been working some PRs this morning for this. 16:21:32 I am not sure if they will be done today, but possibly so 16:21:59 i wish we were getting more communication/info from those who want this change to happen 16:22:00 oh, nice. thanks, dustymaybe and walters 16:22:34 because we've been guessing that things have been happening 16:22:43 proposal: let folks work on it today, if not done in time for freeze, they can ask for an exception or move to f30. 16:23:03 I think there's more going on that makes this a complex issue... like, people may leave info in a ticket but not necessarily all of it, i.e. with whom to close a loop 16:23:06 nirik: and "in time for freeze" means 00:00:00 UTC tomorrow? 16:23:16 bowlofeggs: Yes 16:23:21 yep 16:23:23 nirik: I suppose that's our best option 16:23:37 nirik: i'm +1 16:23:55 i commented in the ticket 16:24:10 walters: Thanks, just saw that. So the Pungi configs look like they've been updated 16:24:18 so they basically have like eight hours? 16:24:32 I can also confirm that https://dl.fedoraproject.org/pub/fedora/linux/development/29/Silverblue/ exists 16:24:42 Also https://dl.fedoraproject.org/pub/fedora/linux/development/29/Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-29-20180827.n.0.iso 16:25:07 oooh, nice! 16:25:08 contyk: correct 16:25:09 Which is making me a lot more comfortable about this 16:25:20 so if those things exist, what does not exist? 16:25:26 well, +1 to nirik's proposal 16:25:29 i.e., what is left to do? is the change actually done? 16:25:57 I'm leaning towards saying this is sufficiently complete for Beta 16:26:01 bowlofeggs: there are probably other things like the getfedora.org web page to do 16:26:20 Who is tracking the open issues/driving them forward? 16:26:20 stickster: True, but I think we can probably do that while in Freeze 16:26:25 but I don't think those are blocking issues, in that they're not about technical completion 16:26:29 sgallagh: jinx 16:26:38 yes, getfedora.org has been on my list to look at 16:27:05 there's some more PR's to merge, some signing changes that need to be made live... 16:27:24 * stickster ducks out since he has to grab food before another meeting 16:27:26 +1 to nirik's proposal 16:27:30 we have been on this for like 30min now. 16:27:37 nirik: As Infra/Rel-Eng, could you help shepherd that to completion todaY? 16:27:42 It sounds like we're pretty close 16:27:54 +1 to the proposal, at any rate 16:27:58 yes, I am hoping this meeting would end so I could do work. ;) 16:28:11 Sounds a lot more likely to happen than it did 20 minutes ago, so I'm happy 16:28:22 i'm +1 to nirik, but it also sounds like maybe it's already "good enough for beta" anyway? 16:29:43 I think it will make it, but we will see. 16:30:15 +1 to nirik's proposal but it seems to me hard to get this finished if is not clear what needs to be done 16:30:20 I count +5 (+6 with nirik as well) 16:30:24 OK, +tyll too 16:30:54 * contyk counts too 16:31:26 I see +6 with tyll... 16:32:16 +1 16:32:34 #agreed "Rename Atomic Workstation to Silverblue": let folks work on it today, if not done in time for freeze, they can ask for an exception or move to f30. (+7, 0, -0) 16:32:54 so, again, dstat 16:33:04 dstat set it to modified 16:33:12 so i think that means it's ok 16:33:25 great! 16:33:52 https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&classification=Fedora&component=Changes%20Tracking&list_id=9313935&product=Fedora&query_format=advanced&version=29 16:33:55 I think zbyszek already commented on festival 16:33:57 is the 4 that aren't. 16:34:20 cloud provider updates and label our variants are the last 2 16:34:38 and festival? 16:34:42 we already decided on the labels last week 16:34:54 "Label Out Variants will be go with Contingency Plan 1 if not completed by beta freeze" 16:34:57 last week we said it had until beta to get done 16:34:59 which is tomorrow 16:35:05 so i guess they also have ~8 hours 16:35:13 This has been seeing a flurry of activity. 16:35:39 I think all of the required PRs are out for review, so it's not in terrible shape 16:36:07 I've reviewed them, we need mboddu to merge at this point and it's done, AFAIK 16:36:46 cool 16:36:56 i guess we can check back in on it next week 16:37:12 do we have to? 16:37:33 I mean we already decided that if it's not done by beta freeze, it's the contingency plan 1 16:37:46 Proposal: The pending PRs must be complete in time for Beta Freeze or it gets deferred to F30 16:37:48 The end 16:38:31 sure. +1 16:38:34 feels kinda pointless to vote on the same thing twice, with virtually the same proposal 16:39:12 ok, then let's move on 16:39:16 * sgallagh wants lunch 16:39:39 +1 16:39:47 yes, we only have the festival and the cloud provider image updates left 16:39:54 somehow we didn't talk about the images last week 16:40:30 sgallagh: +1 16:40:57 yeah, although... is there much to do for that before release? thats only about making updates after release right? 16:41:16 festival still didn't go anywhere. proposal: defer to F30 16:41:27 bowlofeggs: +1 16:41:55 bowlofeggs: +1 16:42:01 bowlofeggs: Didn't zbyszek say something about festival earlier in the meeting? 16:42:16 [09:10:29] A quick update on "update festival to 2.5": I went through the sponsorship process for the Change owner, and the Change seems to be on track. 16:42:16 " A quick update on "update festival to 2.5": I went through the sponsorship process for the Change owner, and the Change seems to be on track." 16:42:33 well, it'd be fair to give them those 7 hours 16:42:40 * sgallagh nods 16:43:27 oh i missed that 16:43:36 i also am fine with the 7 hours 16:44:38 yep.... 16:45:14 * bcotton ducks out to pick up kid from school 16:45:36 soooo. cloud images? 16:46:05 so, proposal for festival: Defer to F30 unless implemented by F29 devel freeze 16:46:13 contyk: +1 16:46:24 +1 16:47:09 contyk: +1 16:48:25 jsmith, tyll, maxamillion: ? 16:48:32 +1 16:48:46 +1 16:49:18 #agreed "update festival to 2.5": Defer to F30 unless implemented by F29 devel freeze (+6, 0, -0) 16:49:22 +1 16:49:23 proposal for cloud image updates: defer and check next week, it's unclear to me what would need to be done before beta as this change deals with post GA content. 16:49:26 :) 16:49:32 nirik: +1 16:49:35 nirik: +1 16:49:37 +1 16:49:47 nirik: +1 16:50:11 does anyone want to check with the proposal owner? 16:50:18 otherwise we'll be just as clueless next week 16:50:21 nirik: +1 16:50:34 #action bowlofeggs will ask for an update from the change owner 16:50:47 bowlofeggs: thanks. 16:50:54 whee 16:50:55 +1 16:51:16 i just posted on the ticket to ask for an update 16:51:37 #agreed cloud image updates: defer and check next week, it's unclear to me what would need to be done before beta as this change deals with post GA content (+7, 0, -0) 16:51:58 ok, I think that's all from the agenda 16:52:03 #topic Next week's chair 16:52:48 crickets 16:53:24 i will not be present next week 16:53:27 it's a US holiday 16:53:33 ah 16:53:37 same 16:53:38 should we skip a week? 16:53:50 oh yeah... 16:53:51 wait, did we cover dstat and I missed it? 16:53:51 although that would affect most of our decisions today 16:54:05 maxamillion: it was updated as modified / on track 16:54:14 hrmmm... 16:54:15 alright 16:54:31 I have issue with the change itself, but we can discuss some other time. I'll take it up in the bug tracker 16:54:55 ok, am I the only one who will be around next week? 16:55:05 tyll too, I think 16:55:46 yes, I should be there, too 16:55:51 6 of the members are from the US 16:56:05 so if assume they will all not be present (not sure if that's sound), we won't have quorum 16:56:20 if we move it by a week, we won't be able to check on all those changes in a week, though 16:56:26 well, I guess there's no way around that 16:56:48 proposal: next meeting will be on September 10 16:57:07 +1, and i volunteer to chair that one 16:57:13 awesome 16:58:31 nirik, sgallagh, jsmith, maxamillion, tyll: ? 16:58:52 +1 16:58:53 +1 16:58:55 +1 to September 10th 16:59:14 sure, +1 16:59:28 +1 16:59:39 #info Due to holidays, the next meeting will be on September 10 16:59:56 #action bowlofeggs will chair the next meeting 17:00:03 #topic Open Floor 17:00:06 anything for the open floor? 17:00:54 proposal: let's assume that people that make a proposal are +1 to their own proposal 17:00:55 not I 17:01:05 bowlofeggs: I abstain 17:01:06 bowlofeggs: +1 17:01:09 because we frequently ask if the person is +1 17:01:10 haha 17:01:15 I'm probably the worst at that 17:01:18 (i'm +1 to my proposal) 17:01:33 that sure was a long meeting for just three items on the agenda 17:01:36 bowlofeggs: +1 17:01:39 it really 17:01:40 was 17:01:48 but at least there wasn't any rubber stamping 17:02:23 bowlofeggs: Agreed :-) 17:02:29 ok, let's end this :) 17:02:34 #endmeeting