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