15:01:40 <mhroncok> #startmeeting FESCO (2019-02-04)
15:01:40 <zodbot> Meeting started Mon Feb  4 15:01:40 2019 UTC.
15:01:40 <zodbot> This meeting is logged and archived in a public location.
15:01:40 <zodbot> The chair is mhroncok. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:40 <zodbot> The meeting name has been set to 'fesco_(2019-02-04)'
15:01:40 <mhroncok> #meetingname fesco
15:01:40 <zodbot> The meeting name has been set to 'fesco'
15:01:40 <mhroncok> #chair nirik, bowlofeggs, jforbes, zbyszek, tyll, sgallagh, contyk, mhroncok, otaylor
15:01:40 <zodbot> Current chairs: bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh tyll zbyszek
15:01:40 <mhroncok> #topic init process
15:01:47 <mhroncok> contyk: I got connected
15:01:50 <zbyszek> .hello2
15:01:51 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:01:55 <otaylor> .hello2
15:01:56 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:01:59 <nirik> morning
15:02:00 <sgallagh> .hello2
15:02:01 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:02:34 <contyk> mhroncok: cool
15:02:38 <contyk> .hello psabata
15:02:39 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:02:41 <bowlofeggs> .hello2
15:02:42 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:03:12 <bowlofeggs> are you guys ready to steer some things, together, as a committee?
15:03:24 <bowlofeggs> do we have 9 steering wheels on this bus?
15:03:28 <bowlofeggs> how does that even work?
15:03:52 <zbyszek> Do we have to by unamimous or things go wonky?
15:03:59 <mhroncok> bowlofeggs: so much philosophy
15:04:00 <smooge> you have 9 wheels
15:04:16 <bowlofeggs> haha
15:04:49 <mhroncok> I guess we have quorum
15:05:02 <smooge> all of them unicycles
15:05:03 <sgallagh> bowlofeggs: I think it's more like having nine oars.
15:05:13 <sgallagh> Four on either side of the boat, one acting as a rudder
15:05:35 <sgallagh> (Or anchor, if you prefer)
15:05:41 <mhroncok> the oar comittee
15:05:52 <bowlofeggs> sgallagh: ha yeah that is a better but less funny analogy ☺
15:06:09 <sgallagh> bowlofeggs: Until you imagine the scene, sure!
15:06:12 <mhroncok> #topic #1970 Action needed: Orphan packages will be retired if they remain  orphaned for six weeks
15:06:12 <mhroncok> .fesco 1970
15:06:12 <mhroncok> https://pagure.io/fesco/issue/1970
15:06:14 <bowlofeggs> haha
15:06:35 <mhroncok> so about orphans
15:06:59 <mhroncok> the retirement happens due to a volunteer that does it every week
15:07:06 * bowlofeggs spends 5 minutes scrolling his mouse wheel to the bottom of this ticket
15:07:14 <mhroncok> it's not *that* tedious actually
15:07:23 <zbyszek> bowlofeggs: <END> ?
15:07:25 <mhroncok> the problem here is that there is no actual policy about depndent packages
15:07:29 <bowlofeggs> haha
15:07:40 <bowlofeggs> yeah the dependent package thing is tricky
15:07:51 <mhroncok> one extreme is: retire them as well, show no mercy
15:07:57 <bowlofeggs> on one hand, it's tempting to just say "they get orphaned too"
15:08:05 <bowlofeggs> but what if they happent o be really important packages
15:08:12 <mhroncok> the other extreme is: let them be, everything-is-fine.jpeg
15:08:16 <sgallagh> I think we just ignore them until they fail their next mass-rebuild
15:08:18 <bowlofeggs> we do have a list of "really improtant packages" in the critpath package list
15:08:24 <nirik> middle might be wait and get them next cycle
15:08:37 <mhroncok> sgallagh: FTBFS ones are easy
15:08:37 <sgallagh> bowlofeggs: That list is very much out of date
15:08:42 <nirik> (or what sgallagh said more coherently)
15:08:43 <bowlofeggs> (critpath package list is not well maintained)
15:08:43 <mhroncok> it's the runtime problems that i worry about
15:08:46 <bowlofeggs> yeah
15:08:55 <otaylor> critpath also doens't really mean "really important" as much as "necessary to boot to a desktop"
15:09:21 <zbyszek> I think such deps are often forgotten and/or semi-optional, so orphaning dependent packages seems like too big of a step for me
15:09:27 <sgallagh> mhroncok: Well, runtime problems tend to get noticed by automatic QA processes
15:09:29 <mhroncok> and the FTBFS orphan / retire policy doesn't happen either, so not so much luck there
15:09:31 <bowlofeggs> otaylor: true (or is it "included in one of the official ISOs, or a dependency of a package included in an official ISO?")
15:09:35 <sgallagh> So I think we'd have a quick turnaround there
15:09:55 <bowlofeggs> i don't mind letting the next FTBFS round pick them up
15:10:03 <bowlofeggs> the "middle option" as nirik stated
15:10:18 <mhroncok> as long as we have a policy and actual process running for FTBS **and** broken deps, we are good
15:10:21 <mhroncok> nether is true
15:10:24 <bowlofeggs> yeah
15:10:42 * zbyszek intends to spend some time on the FTBFS-retirement after this mass reubild
15:10:44 <mhroncok> I don't mind letting the next FTBFS round pick them up if that actually means something
15:10:47 <bowlofeggs> i'm a little scared of just retiring deps too, though i am not sure i'm opposed to that
15:11:04 <otaylor> We should also think about EPEL here - that's the only place where retirement affects a current release, if I'm not mistaken?
15:11:09 <tyll_> .hello till
15:11:10 <zodbot> tyll_: till 'Till Maas' <opensource@till.name>
15:11:13 <bowlofeggs> the downside to the next round is that could be a long time (6ish months)
15:11:26 <mhroncok> otaylor: yet the policy for orphanned packages doesn't spek of retiring them on epel
15:11:32 <bowlofeggs> otaylor: i'm not sure we touch EPEL with this, do we?
15:11:35 <jforbes> we have to at least warn deps
15:11:42 <bowlofeggs> jforbes: i think we do that now
15:11:45 * mhroncok only retires packages in rawhide
15:11:56 <tyll> in the past I retired dependent packages as well... and they could still be unretired in case they are important
15:11:56 <otaylor> bowlofeggs: if a package is orphaned, it's orphaned for EPEL too, right?
15:12:00 <mhroncok> jforbes: I bomp them with e-mail for 6 weeks
15:12:04 <bowlofeggs> otaylor: i don't think so
15:12:05 <mhroncok> jforbes: they don't care
15:12:08 <bowlofeggs> oh yes
15:12:11 <bowlofeggs> otaylor: yes you are right
15:12:16 <bowlofeggs> but we don't *retire* it there
15:12:28 <mhroncok> until they are "oh no, thi isn't here anymore, where did it go, it was right here 8 years ago and now it isn't"
15:12:44 <bowlofeggs> mhroncok: haha "bomp"
15:12:52 <smooge> otaylor, bowlofeggs so in the past a package would have branch owners and so would be 'owned' in EPEL but orphaned in main
15:12:54 <mhroncok> supposed to be bomb
15:12:57 * nirik leans toward just retiring the dependent ones (with enough notice)
15:12:58 <bowlofeggs> mhroncok: you should put "bomp" in the subject line
15:13:20 <smooge> we sort of have people who don't want to maintain things in Fedora as much as Fedora packagers have things they don't want to look at in EPEL
15:13:30 <bowlofeggs> the one good thing about retiring is that it's easy to unretire if it's done quickly enough
15:13:46 <mhroncok> yet it put unnecessary work on releng
15:13:46 <bowlofeggs> within some number of weeks you can unretire without re-review iirc
15:13:50 <bowlofeggs> also true
15:13:50 <mhroncok> 2 weeks
15:14:04 <mhroncok> and if tahey ahven't noticed in 6 weeks, those 2 weeks are not gonna change that
15:14:20 <bowlofeggs> mhroncok: yeah that's probably true
15:14:20 <nirik> the epel interactions here are much less clear than they used to be... and somewhat confusing.
15:14:21 <tyll> mhroncok: if they do not notice, then the package can be rightfully retired
15:14:35 <mhroncok> tyll: I tend to agree
15:14:40 <bowlofeggs> i think i could support any of the proposed options
15:14:54 <mhroncok> yet I get the "sigh" emails "I've juts noticed this" after couple months
15:15:10 <mhroncok> I think that retirement is too much
15:15:10 <nirik> thats always going to happen I fear
15:15:15 <bowlofeggs> yeah
15:15:22 <mhroncok> at least half of the cases the dependency can go away
15:15:30 <otaylor> That actually argues for retiring dependent packages so that people notice asap, on the other hand, there has to be some "human touch" there - since we don't want to retire a huge bunch of packages, then have to fix it all up afterwards
15:15:49 <smooge> we get similar emails still for people who find their accounts were locked out from a password change 7 years ago
15:15:56 <mhroncok> ideally, we'd have a mechanism that opens a bug (or similar) as soon as package starts to FTBS and/or has problematic runtime deps
15:16:01 <bowlofeggs> mhroncok: i wonder if it would be good to send an e-mail per package about retiring that package, rather than a single e-mail with all the packages to the packagers, and then *also* send the single e-mail with all packages to devel list?
15:16:10 <zbyszek> That's why I like taking the slightly slower route of filing FTBFS for depdent packages
15:16:12 <mhroncok> there would be a deadline to fix them, or retirement happens after
15:16:20 <bowlofeggs> that might catch people's attenotion, because the e-mail that goes to their inbox would be more targeted?
15:16:23 <bowlofeggs> just an idea…
15:16:40 <tyll> bowlofeggs: they got the same e-mail both to inbox and the mailing list
15:16:50 <mhroncok> depends on their filters really
15:17:19 <mhroncok> zbyszek: the FTBFS only solves the buildtime deps problem
15:17:20 <bowlofeggs> tyll: yeah but the e-mail in the inbox makes you ctrl-f for your nick to see which packages affect you
15:17:39 <bowlofeggs> it's not bad as it is now, i'm just considering whether it would help
15:17:44 <bowlofeggs> might not
15:17:47 <mhroncok> bowlofeggs: might help a little
15:17:48 <nirik> well, if you got it it does
15:17:58 <mhroncok> bowlofeggs: probably not worth dealing with dozens of emails every week
15:18:02 <mhroncok> until a bo runs this
15:18:04 <bowlofeggs> mhroncok: yeah maybe not
15:18:08 <mhroncok> *bot
15:18:22 <bowlofeggs> so who feels strongly about the options we've proposed? i would +1 any of them honestly
15:18:34 <tyll> IMHO it would be nice to send out a notification direclty when a package is orphaned to all the co-maintainers and the maintainers of directly dependent pkgs to make them aware
15:18:38 * otaylor tries to avoid speculating about how we could do packager notifications better in absence of resources to actually improve things
15:18:46 <tyll> AFAIK there is no notification if a package is orphaned atm
15:18:59 <mhroncok> there is fedmsg
15:19:05 <mhroncok> (or at least I hope there is)
15:19:08 <tyll> fedmsg is not a notification system
15:19:16 <mhroncok> and there is a fedmsg -> e-mail notification thing
15:19:25 <bowlofeggs> and fedmsg --> iRC too
15:19:29 <mhroncok> so this could (maybe) be easy
15:19:34 <mhroncok> or not :D
15:19:35 <tyll> yes, but they do not notify atm
15:19:41 <jforbes> Yeah, question of how people have their fedmsg filters set up
15:19:53 <tyll> they do not notify by default
15:20:00 <nirik> we could emit messages about this, but not sure how much better than emails that would really end up being
15:20:12 <mhroncok> also, the filter to notify me when a dependncy is orphaned is probably nontrivial
15:20:20 <bowlofeggs> i think we currently do a good job of notifying that we are going to orphan packages
15:20:26 <bowlofeggs> i certainly see and look at those e-mails anyway
15:20:34 <mhroncok> I tend to agree
15:20:42 <mhroncok> people are ignoring those becasue they know nothign happens
15:20:51 <mhroncok> so we should make something happen and they'll get used to this
15:21:10 <bowlofeggs> yeah maybe we should just do *something* and see how it goes>?
15:21:17 <bowlofeggs> we can readjust our policy later if needed
15:21:29 <mhroncok> +1 to do something
15:21:33 <bowlofeggs> as said, i don't feel strongly about which something we do
15:21:40 <zbyszek> So the crucial difference for *dependent* packages is that until the orphaning actually happens, there's nothing to do for the maintainers. They can rightfully hope that somebody will pick up the package.
15:21:40 <bowlofeggs> i'll +1 any of the three we've talked about
15:21:45 <mhroncok> -1 to retire deps when we retire the orphaned package
15:22:17 <mhroncok> I remember getting a daily e-mail "your package has broken deps", it stopped couple years ago
15:22:28 <bowlofeggs> yeah that was useful, i remember that oo
15:22:31 <zbyszek> That's why I think immediately retiring (or acting in any immediate way) on dependent packages at the same time as the dependended-upon package is too soon.
15:22:32 <nirik> yep. it broke due to rich deps
15:22:34 <bowlofeggs> i use koschei too
15:22:39 <bowlofeggs> oh yeah, rich deps
15:22:42 <nirik> there's a new one that has been having issues getting to work...
15:22:47 <zbyszek> It'd be great to bring this back.
15:23:18 <nirik> https://pagure.io/releng/issue/6365
15:23:33 <mhroncok> even a once per release, generate bugzillas for broken deps and apply FTBFS rules would work for me
15:23:49 <nirik> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190204.n.0/logs/depcheck
15:24:03 <nirik> (without arm and aarch64)
15:24:28 <tyll> mhroncok: actually there was a rule to retire pkgs with broken deps before branching
15:24:41 <tyll> (to be added to the list of things that are not happening anymore)
15:24:48 <bowlofeggs> so it sounds like there's less support for the "extreme option" (retiring deps immediately)
15:25:01 <mhroncok> bowlofeggs: yes, that's correct
15:25:14 <zbyszek> Yeah, I'd be against
15:25:14 <jforbes> Yeah, I have a hard time with that option
15:25:17 <nirik> so how about the 'let dependent packages get caught in FTBFS process'
15:25:33 <mhroncok> nirik: that doesn't solve runtime only deps
15:25:38 <bowlofeggs> the remaining options are to let the FTBFS naturally pick it up next cycle (slooow), or to immediately file a FTBFS upon retiring (medium speed)
15:25:49 <mhroncok> I'm Ok with slow
15:25:53 <sgallagh> mhroncok: I still feel that runtime-only deps will get noticed by automation
15:25:55 <mhroncok> as long as it also covers runtime
15:25:57 * tyll prefers medium speed
15:26:04 <mhroncok> sgallagh: they are not
15:26:07 * nirik likes medium speed too
15:26:18 <bowlofeggs> sometimes missing deps don't mean FTBFS
15:26:28 <bowlofeggs> there are some deps that are runtime only
15:26:32 <mhroncok> and the FTBFS could be quite medium speed, if the policty there actually happens
15:26:32 <sgallagh> mhroncok: I don't mean the missing-deps tests
15:26:35 <zbyszek> Automation in the form of gating will hopfully appear in the non-too-distant future
15:26:38 <sgallagh> I mean the actual functional tests.
15:26:53 <sgallagh> If things that aren't part of the installed media are broken, that's less worrisome to me
15:26:56 <zbyszek> I like the medium sped best.
15:26:58 <mhroncok> that's a fairy tale ATM
15:26:58 <bowlofeggs> i dont' think we have a "Fail to Install" test, do we?
15:27:04 <bowlofeggs> other than koschei
15:27:22 <nirik> we easily could with rawhide gating.
15:27:37 <mhroncok> gating happens on new build, correct?
15:27:42 <bowlofeggs> if we immediately file a FTBFS when we retire a dependency, we could detect what to file based on Requires AND BuidRequires
15:27:44 <mhroncok> so let's say A needs B
15:27:46 <mhroncok> we retire B
15:27:49 <nirik> yeah, so it wouldn't catch old things.
15:27:53 <bowlofeggs> which i think might be more thorough than FTBFS
15:27:55 <mhroncok> A has broken deps, what does gatin do and  when?
15:28:15 <bowlofeggs> yeah i guess automation could catch Fail to Install
15:28:23 <bowlofeggs> and we are working towards gating rawhide
15:28:26 <mhroncok> it definitively should
15:28:32 <mhroncok> automate all the things \o/
15:28:48 <mhroncok> yet I don't like to plan policies on top of "this should be automated"
15:28:49 <zbyszek> mhroncok: I think *any* test is bound to fail if the package cannot be installed.
15:28:52 <bowlofeggs> bodhi has a number of open pull requests for gating rawhide!
15:29:25 <mhroncok> this has been a long dicsussion
15:29:28 <bowlofeggs> yeah
15:29:28 <mhroncok> do we sish to continue
15:29:30 <mhroncok> ?
15:29:33 <mhroncok> wish
15:29:35 <nirik> it's high on the infra priority list...
15:29:37 <zbyszek> I think it's fine to set a policy that depends on stuff that we expect to happen soon
15:29:44 <bowlofeggs> is anyone opposed to the slow option?
15:29:50 <bowlofeggs> just let FTBFS pick it up next round?
15:29:58 <bowlofeggs> keep in mind we are free to change our minds later
15:30:02 <bowlofeggs> not a permanent decision
15:30:07 <zbyszek> Not opposed.
15:30:15 <tyll> IMHO letting FTBFS pick up is like doing nothing
15:30:16 <mhroncok> bowlofeggs: that is the status quo
15:30:21 * nirik is fine with that for now, but not handling the runtime deps is not great
15:30:23 <mhroncok> tyll: exactly
15:30:33 <otaylor> I'm not opposed, it wold be great if we had immediate notification to maintainers of dependent packagers ... but that's a bonus, not a requirement
15:30:36 <tyll> but we agreed we want to do something :-)
15:30:54 <bowlofeggs> well, the medium option requires more work right? is anyone available to do that? i'd +1 it too
15:31:32 <zbyszek> I think we can vote conditionally that the medium option is wanted, and we ask volunteers to work on the implmenetation.
15:31:40 <bowlofeggs> sure
15:31:41 <tyll> if nobody is going to implement it, then I would be more in favor of retiring dependent pkgs directly
15:32:35 <tyll> I mean if nobody is implementing the medium option
15:32:37 <mhroncok> so "the medium speed" thing is: when a long orphaned package is retired, bugz are filled for dependent packages and FTBFS-like policy applies there
15:32:46 <mhroncok> filed
15:32:51 <bowlofeggs> yeah
15:32:55 <zbyszek> ack
15:32:57 <bowlofeggs> and then they get their 6 weeks to respond
15:33:05 <bowlofeggs> if someone can implement that, that does sound ideal to me
15:33:24 <zbyszek> Shouldn't be *that* hard.
15:33:34 <mhroncok> for the record: until that is automated, I'm not going to file those bugzillas when i retire packages
15:33:34 <nirik> +1
15:33:35 <bowlofeggs> maybe since we are so powerful as FESCo, we can just *demand* that someone implement it ☺
15:33:53 <sgallagh> .fire bowlofeggs for getting overconfident
15:33:53 <zodbot> adamw fires bowlofeggs for getting overconfident
15:33:55 <nirik> bowlofeggs: we could, but it wouldn't do much good. ;)
15:33:57 <bowlofeggs> hahaha
15:33:58 <mhroncok> bowlofeggs: sure, we demand you do it
15:34:01 <bowlofeggs> hahaha
15:34:10 <jforbes> Yeah, that seems to work.   We just will things into existence.
15:34:13 <zbyszek> +1 too
15:34:43 <bowlofeggs> could we approve the slow option *and* the medium option
15:34:45 <bowlofeggs> ?
15:34:50 <tyll> actually to implement the mediums speed thing, someone also needs to actually retire the long-time FTBFS pkgs
15:34:56 <mhroncok> bowlofeggs: the slow option doesn't need to be approved
15:34:59 <bowlofeggs> allowing someone to implement the medium option, and just do the slow option until then?
15:35:02 <nirik> well, the slow option doesn't need any approval, it's what we are doing now?
15:35:19 <bowlofeggs> sure
15:35:28 <bowlofeggs> ok, so let's just vote on the medium thing and hope that someone does it?
15:35:30 <bowlofeggs> hahaha
15:35:56 * tyll is not +1 for medium if it is not going to happen - then I would prefer the immediate retirement
15:36:01 <bowlofeggs> we could advertise that we need some help on devel list
15:36:04 <bowlofeggs> that might get someone
15:36:28 <jforbes> Asking nicely always helps more than demanding
15:36:43 <mhroncok> proposal: I'll summarize this on the ticket, send an email do devel asking for help
15:36:44 <nirik> lets try and get some help, if it fails revisit next week?
15:36:49 <bowlofeggs> jforbes: but it's more fun to say "the power of fesco compels you!"
15:37:09 <bowlofeggs> mhroncok, nirik: +1
15:37:32 <nirik> +1 mhroncok
15:37:44 <zbyszek> mhroncok: +1
15:37:56 <sgallagh> mhroncok: +!
15:37:58 <sgallagh> +1
15:38:00 <jforbes> mhroncok: +1
15:38:18 <otaylor> +1
15:38:33 <mhroncok> # action mhroncok will summarize this on the ticket, send an email to devel asking for help
15:38:36 <tyll> mhroncok: +1
15:38:41 <mhroncok> I don't think we need a formal vot for this
15:38:47 <mhroncok> next topic
15:39:02 <mhroncok> #topic #2060 F30 System-Wide Change: DNF Better Counting
15:39:02 <mhroncok> .fesco 2060
15:39:02 <mhroncok> https://pagure.io/fesco/issue/2060
15:39:21 <mhroncok> zbyszek sent  aproposal 7 days agao
15:39:33 <nirik> oh, missed it. +1 to that
15:39:35 <mhroncok> technically this should get autoapproved today
15:39:49 <mhroncok> yet +2 is not too confident
15:40:12 <mhroncok> that is +3 now with nirik
15:40:32 <mhroncok> is there anyone who would want more time for this?
15:40:46 <tyll> I am not sure why the implementation will hape to make it clearer how to do the countme syntax
15:40:51 <tyll> will help
15:41:01 <sgallagh> +1
15:41:16 <zbyszek> tyll: Because when implmenting things, details of design are much easier to see
15:41:25 <sgallagh> I thought I had +1'ed that already
15:41:40 <jforbes> +1
15:42:32 <mhroncok> do i see +5?
15:43:00 <tyll> zbyszek: the implementation of the reporting is rather simple AFAICS, if at all then implementing the analytics with some real data would help to figure out whatis needed
15:43:01 <mhroncok> I suppose zbyszek is +1 as well, or definitively not -1
15:43:10 <bowlofeggs> +1 from me too (also in ticket just now)
15:43:23 <zbyszek> mhroncok: we voted (previous fesco) that the proposer is automatically +1
15:43:38 <mhroncok> zbyszek: good to know, not sur if documented
15:43:53 <mhroncok> that is +7
15:44:01 * tyll is 0
15:44:05 <mhroncok> tyll: thanks
15:44:09 <zbyszek> (they can always change to -1 explicitly, but that's rather rare)
15:44:25 <zbyszek> mhroncok: I'll try to find the reference.
15:44:40 <mhroncok> tyll: do you think we should give this more discussion?
15:44:47 <bowlofeggs> it saved us from a bunch of "hey <person>, are you for your own proposal?" questions
15:44:49 <bowlofeggs> haha
15:45:29 <tyll> mhroncok: IMHO we should agree on/approve an actual specification
15:45:57 <tyll> currently it is very vague
15:46:24 <mhroncok> would we want to say "proceed with the change, yet submit it for re-approval once implemented"?
15:46:40 <mhroncok> also not sure if this shouldn't be approved by council as well
15:47:00 <bowlofeggs> mhroncok: that's a good suggestion
15:47:12 <bowlofeggs> we can say that we like the direction but want to see more detail for final approval
15:47:45 * mhroncok would +1 that
15:48:07 <zbyszek> I'd trust the people involved to make a reasonable choice. Any of the proposed implementation details seems good enough to me.
15:48:09 <mhroncok> (we technically approved zbyszek's proposal, but I see tyll's point)
15:48:30 <mhroncok> if there isn't enough support for this, we can move on
15:48:42 <zbyszek> If we feel that the implmentation leaks too much information, we can always opne a new ticket.
15:49:25 <tyll> but is now going to be implemented first, countme with a boolean or a counter?
15:49:46 <tyll> What is now...
15:50:39 <nirik> boolean is whats on the change page
15:50:55 <nirik> oh, it has counter as optional
15:51:15 <nirik> so not sure.
15:51:31 <tyll> this is my point, IMHO it should be clear what is going to happen when we approve this
15:51:51 <bowlofeggs> yeah i think what tyll is saying is reasonable
15:51:57 <mhroncok> let's make a second vote so we are sure what we want
15:52:14 <mhroncok> proposal: proceed with the change, yet submit it for re-approval once implemented
15:52:18 <mhroncok> +1
15:52:19 <bowlofeggs> mhroncok: +1
15:52:21 <nirik> I kinda agree. I'm ok with either thing, but it would be good if they said what they were doing...
15:52:47 <tyll> mhroncok: +1
15:52:54 <jforbes> That's just it, I am okay with either thing as well, so why force more overhead?
15:53:25 <zbyszek> jforbes: exactly
15:53:28 <jforbes> I take it by this, tyll is okay with one, but not the other
15:53:36 <mhroncok> zbyszek's proposal has +7,1,-0
15:53:56 <mhroncok> this proposal is +5 if I count "I'm OK with both"
15:54:27 <otaylor> I'm +1 for either if it moves things forward, but do trust people to implement it with privacy in mind and come back and ask us if it's not clear
15:54:30 <bowlofeggs> flipping tyll to a +1 is a good thing too though imo
15:55:08 <bowlofeggs> +8, 0, -0 is a little better than +7, 1, -0
15:55:19 <nirik> I think anyone can see the implementation and raise concerns then... bringing it back for another approval round seems like a lot of overhead... but sure.
15:55:28 <jforbes> mhroncok: Okay with either thing in this regard, meant the bool or counter.  I am not particularly in favor of forcing more red tape if no one is against their implementation
15:55:32 <bowlofeggs> i'm also fine either way
15:55:32 <tyll> since it is a sensitve topic, I would in favor to have the actual implemention under crucial review even though if I trust the implementers to handle in good faith they might miss something
15:56:32 <mhroncok> I guess we can always volunteer to review the code
15:56:35 <nirik> sure, I guess we can...
15:56:38 <zbyszek> I'll vote +1 to the updated proposal, even though I don't think this additional step is necessary
15:57:50 <mhroncok> tyll: would you be willing to act as a fesco shepherd on this thing or whatever is that thing called?
15:58:34 <tyll> mhroncok: not sure I understand what you are asking
15:59:08 <mhroncok> my idea is that we approve the change, but you personally would work with the change owners to make sure the implementation is good(tm)
15:59:43 <mhroncok> you would act as a fesco delegate in the matter, making sure it doesn't go crazy
16:00:00 <mhroncok> (it's just an idea)
16:00:58 <tyll> mhroncok: sure, I can review it again
16:01:16 <mhroncok> tyll: does that keep you at 0?
16:02:03 <tyll> mhroncok: eh, I guess so, because this means that I would be giving my approval later after I reviewed it...
16:02:10 <mhroncok> sure
16:02:40 <mhroncok> #action tyll will work with change owners to make sure the actual implementation is sane
16:02:57 <mhroncok> #agree APPROVED (+7, 1, 0)
16:03:04 <mhroncok> (goes for the change)
16:03:58 * mhroncok waits couple seconds if somebody has a bureaucratic remark about what i just did
16:04:53 <sgallagh> nirik: does #agree also work, or does zodbot recognize only #agreed?
16:04:55 <bowlofeggs> "you are technically correct, the best kind of correct." -a bureaucrat from futurama
16:05:17 <mhroncok> https://fedoraproject.org/wiki/FESCo_meeting_process says afree
16:05:18 <nirik> I think it may only be agreed...
16:05:19 <mhroncok> agree
16:05:25 <mhroncok> #agreed APPROVED (+7, 1, 0)
16:05:30 <mhroncok> anyway npow we have both
16:05:33 * nirik looks
16:05:46 <sgallagh> Yeah, I noticed that in the Wiki recently and meant to ask
16:06:00 * mhroncok waits
16:06:01 <nirik> either works
16:06:03 <mhroncok> good
16:06:03 <sgallagh> ok
16:06:13 <mhroncok> #topic #2065 F30 System-Wide Change: GCC9
16:06:13 <mhroncok> .fesco 2065
16:06:13 <mhroncok> https://pagure.io/fesco/issue/2065
16:06:24 <sgallagh> This is already approved, is it not?
16:06:33 <sgallagh> It's de facto approved at any rate
16:06:41 <sgallagh> Since we held the mass-rebuild for it
16:06:43 <mhroncok> sgallagh: by whoom?
16:06:49 <bowlofeggs> it didn't get to 7 days yet
16:06:53 <jforbes> Formality, in that we approved holding the mass rebuild for it
16:07:06 <mhroncok> this actually makes me wanna go -1 just to enjoy some fun :D
16:07:11 <nirik> anyhow, +1 here.
16:07:11 <nirik> ha
16:07:25 <sgallagh> +1
16:07:30 <jforbes> +1
16:07:32 <mhroncok> it didn't go 7 days and until now there was no vote
16:07:38 <tyll> +1
16:07:54 <mhroncok> mass rebuild has usual number of failures
16:07:56 <mhroncok> so +1
16:08:05 <bowlofeggs> +1
16:08:27 <sgallagh> I really think this was covered under
16:08:28 <sgallagh> .fesco 2066
16:08:29 <zodbot> sgallagh: Issue #2066: Delay mass rebuild by a day, that is on Jan 31st 2019 - fesco - Pagure.io - https://pagure.io/fesco/issue/2066
16:08:42 <mhroncok> sgallagh: no, that was clearly about delaying the mass rebuild
16:08:54 <mhroncok> it said nothign about our approval of gcc9
16:09:08 <sgallagh> It was specifically to delay the mass rebuild so that gcc9 wouldn't break it
16:09:17 <mhroncok> yes
16:09:28 <mhroncok> I don't reead that as automatically approving the gcc9 change
16:09:29 <sgallagh> but if you feel that we need more rubber-stamping, go ahead
16:09:33 <mhroncok> is that important?
16:09:52 <mhroncok> anyway this is approved tehcnically as we speek
16:10:09 <mhroncok> #agree APPROVED (+6, 0, 0)
16:10:13 <tyll> sgallagh: we need at least proper documentation that it was approved
16:10:22 <tyll> sgallagh: would not call it rubber-stamping
16:10:26 <mhroncok> here goes the rubber stamp
16:11:05 <jforbes> The whole process was a bit messy this time. This was communicated to the owners, so hopefully will be better next time.
16:11:44 * mhroncok hopes as well
16:11:49 <mhroncok> #topic Next week's chair
16:12:06 <mhroncok> (everybody hides)
16:12:19 <jforbes> I can do it
16:12:29 <mhroncok> jforbes++
16:12:29 <zodbot> mhroncok: Karma for jforbes changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:12:43 <mhroncok> #action jforbes chairs next meeting
16:12:55 <mhroncok> #topic Open Floor
16:13:13 <mhroncok> who decides fedora 31 schedule?
16:13:18 * nirik notes the mass rebuild is all done (except for a few stragglers)... hopefully merged soon/today
16:13:32 <mhroncok> (and when)
16:13:52 <nirik> fpm usually proposes one for us to review...
16:14:30 <zbyszek> IIUC, the plans to delay F31 have been dropped
16:14:52 * mhroncok has a Fedora 31 change proposal draft and it very much depends on the schedule, that's why the question happened
16:15:09 <mhroncok> would need to delay it as well, but maybe for a week or two, not for months
16:15:26 <mhroncok> to line up better with Python 3.8
16:15:38 <zbyszek> Oh, I saw that 3.8a1 is out
16:15:52 <mhroncok> anyway, I'll just talk to ben and get the change proposed as early as possible
16:16:02 <mhroncok> for reference https://fedoraproject.org/wiki/Changes/Python3.8
16:16:07 <mhroncok> (still draft)
16:16:09 <zbyszek> Is there a copr or something to try it out?
16:16:13 <bowlofeggs> does python 3.8 do my job for me?
16:16:18 <bowlofeggs> that would be a cool feature…
16:16:25 <mhroncok> zbyszek: I'll package python38 asap
16:16:37 <mhroncok> bowlofeggs: the one where you implement the stuff fesco agrees on?
16:16:42 <bowlofeggs> haha
16:16:44 <bowlofeggs> yeah
16:16:46 <zbyszek> mhroncok++
16:16:46 <bowlofeggs> that one
16:17:08 <bowlofeggs> import bowlofeggs
16:17:09 <mhroncok> bowlofeggs: no, that unfortunately only works on python 2
16:17:14 <bowlofeggs> bowlofeggs.start_event_loop()
16:17:25 <bowlofeggs> oh no, bowlofeggs is getting deprecated‽
16:17:26 <mhroncok> will end the meeting in 5 minutes
16:18:10 <mhroncok> deprecated, orphaned and retired... :D
16:18:30 <mhroncok> note that there's still the yum proposal on devel list
16:18:43 <mhroncok> so f30 changes are not yet over
16:22:07 <mhroncok> bye all
16:22:12 <mhroncok> #endmeeting