15:00:00 <bowlofeggs> #startmeeting FESCO (2018-11-19)
15:00:00 <zodbot> Meeting started Mon Nov 19 15:00:00 2018 UTC.
15:00:00 <zodbot> This meeting is logged and archived in a public location.
15:00:00 <zodbot> The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:00 <zodbot> The meeting name has been set to 'fesco_(2018-11-19)'
15:00:03 <bowlofeggs> #meetingname fesco
15:00:03 <zodbot> The meeting name has been set to 'fesco'
15:00:05 <bowlofeggs> #chair nirik, maxamillion, jsmith, jforbes, zbyszek, tyll, sgallagh, contyk, bowlofeggs
15:00:05 <zodbot> Current chairs: bowlofeggs contyk jforbes jsmith maxamillion nirik sgallagh tyll zbyszek
15:00:06 <bowlofeggs> #topic init process
15:00:11 <nirik> morning
15:00:20 <maxamillion> .hello2
15:00:21 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:00:22 <jsmith> .hello2
15:00:24 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
15:00:34 <mhroncok> hi
15:01:14 <sgallagh> .hello2
15:01:15 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:17 <sgallagh> (sort of)
15:01:28 <zbyszek> .hello2
15:01:29 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:03:03 <maxamillion> I actually don't have a conflict in this time slot this week \o/
15:04:29 <bowlofeggs> i've  got a roofer coming probably during this meeting
15:04:43 <bowlofeggs> i sent my IRC-friendly agenda notes to the fesco list
15:04:48 <jsmith> (Apologies for missing the meeting the last couple of weeks -- ${DAYJOB} has been crazy)
15:04:51 <bowlofeggs> can someone take over when/if that happens?
15:05:10 <zbyszek> bowlofeggs: I'd be happy to
15:05:15 <bowlofeggs> we have 6 so we should be able to keep quorum if i need to leave
15:05:19 <bowlofeggs> cool
15:05:27 <bowlofeggs> also i probably don't need to spend that much time with the roofer
15:05:35 <bowlofeggs> so might just disappear for 5-15 min or so
15:05:40 <bowlofeggs> alright, let's get this party started
15:05:53 <bowlofeggs> #topic #1970 Long orphaned packages are not being retired after 6 weeks
15:05:56 <bowlofeggs> .fesco 1970
15:05:58 <zodbot> bowlofeggs: Issue #1970: Action needed: Orphan packages will be retired if they remain orphaned for six weeks - fesco - Pagure.io - https://pagure.io/fesco/issue/1970
15:06:31 <bowlofeggs> mhroncok: you are up!
15:06:35 <mhroncok> thanks
15:06:46 <zbyszek> We desperately need a volunteer to implement this
15:07:11 <mhroncok> so, my questions is: who is responsible for delivering such policies? is it FESCo, otr FESCo just creates the policty and taht's it?
15:07:33 <zbyszek> I don't think there's any rule that would always apply
15:07:36 <mhroncok> are individuals allowed to act on the policy? = retiure packages
15:08:00 <mhroncok> or do we need to formally say how is this policy implemented?
15:08:03 <sgallagh> mhroncok: Strictly speaking, FESCo's job is to make the policy. In practice, it has usually been a FESCo member that has ended up implementing it to.
15:08:05 <sgallagh> *too
15:08:18 <bowlofeggs> i don't think it has to be fesco implementing it
15:08:26 <bowlofeggs> but ACLs may be a problem for most people
15:08:29 <sgallagh> Once the policy is created, I don't have any problems with someone stepping up to do the enforcement.
15:08:36 <zbyszek> We should/need/do always consider implementation posibilities when setting a policy
15:08:38 <sgallagh> (FESCo can play referee if there are disagreements)
15:08:41 <zbyszek> sgallagh +1
15:08:57 <bowlofeggs> sgallagh: +1
15:09:10 <nirik> indeed.
15:09:23 <zbyszek> In this case, it'd be good to have this automated and run by releng, so that it keeps happening without depending on a single individual
15:09:38 <mhroncok> zbyszek: that would be nice, but should not block this
15:09:44 <zbyszek> Yes, sure.
15:09:52 <tyll> anyone can retire orphaned packages IMHO but doing so on a large scale needs to be done responsibly
15:09:53 <sgallagh> Right, but if mhroncok wants to write the tool that releng adds to its automation, I'm all in favor
15:09:55 <mhroncok> I know till had some script to geenrate the reports
15:10:04 <mhroncok> I try to talk to him
15:10:32 <mhroncok> consider me volunteering to do the thing
15:10:35 <zbyszek> mhroncok: in particular, I think it is better to do it "manually" now, then never
15:10:37 <tyll> the scripts for the reports are in the releng git repo
15:10:47 <mhroncok> tyll: thanks
15:10:49 <bowlofeggs> mhroncok++
15:10:49 <nirik> thats excellent. thank you mhroncok.
15:10:51 <sgallagh> #action mhroncok volunteers to script the package retirements
15:10:55 <zbyszek> mhroncok++
15:10:55 <zodbot> zbyszek: Karma for churchyard changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:10:59 <bowlofeggs> anything else on this topic?
15:11:00 <sgallagh> mhroncok++
15:11:00 <zodbot> sgallagh: Karma for churchyard changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:11:13 <tyll> but the latest decision was to re-assing the currently orphaned packages first, there is no script for that
15:11:24 <tyll> at least nothing that is fully ready
15:11:27 <nirik> even tho some things have been orphaned a while, another report run would eb good.
15:11:40 <mhroncok> sgallagh: to retire the packages (I'll start somehow manually and that see what can be automated)
15:11:52 <nirik> (so nothing unexpected gets orphaned thats needed)
15:12:03 <tyll> another problem is that it is not really clear if co-maintainer are properly notified if a package is orphaned
15:12:04 <mhroncok> "but the latest decision was to re-assing the currently orphaned packages first"
15:12:15 <mhroncok> I'ma afraid i cannot do that, don't have the powers
15:12:29 <mhroncok> IV'e requested some rights form releng months ago, nothign happened
15:12:31 <maxamillion> mhroncok++
15:12:31 <zodbot> maxamillion: Karma for churchyard changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:12:42 <nirik> tyll: at one point we had it just reassign to one of them... perhaps that would be better than orphaning
15:12:44 <tyll> mhroncok, if you provide the script I am happy to run it
15:12:57 <bowlofeggs> are special powers needed to find out which packages are orphaned?
15:12:59 <mhroncok> tyll: noted
15:13:04 <sgallagh> #undo
15:13:04 <zodbot> Removing item from minutes: ACTION by sgallagh at 15:10:51 : mhroncok volunteers to script the package retirements
15:13:06 <mhroncok> bowlofeggs: nope, taht i can
15:13:23 <bowlofeggs> oh you mean to mass retire
15:13:25 <mhroncok> also, I think that if we notify all comaintainers
15:13:26 <sgallagh> #action mhroncok volunteers to retire the packages manually and see what can be automated
15:13:34 <mhroncok> and they not claim the package anyway
15:13:37 <bowlofeggs> yeah notification would be great
15:13:43 <mhroncok> we shoudl retire it, not force it to them
15:13:54 <bowlofeggs> +1
15:14:33 <zbyszek> mhroncok: I think reassingment is much better, because if you are an co-maintainer of a package, you presumably care about it
15:14:53 <sgallagh> zbyszek: well, strictly speaking it means you cared about it once upon a time
15:14:53 <zbyszek> Just retiring it could be a rude surprise
15:14:56 <tyll> mhroncok, it is not really forced on them, because they can also drop their maintainership if they do not want the package
15:15:04 <zbyszek> tyll: exactly
15:15:46 <mhroncok> the point I'm trying to make is: ...
15:15:58 <zbyszek> It'd be better for the distro as a whole to encourage co-maintainers to opt-out, rather then retiring massive amounts of packages
15:16:08 <bowlofeggs> i agree with zbyszek
15:16:14 <Son_Goku> likewise
15:16:36 * nirik nods.
15:16:38 <mhroncok> if we send notifications to them (the list of orphaned packages) and they do not care enough to claim the package, they are most likely ignoring it and reassigning to them only postpones the retirement and waits for another nonrepsonsive process to happen
15:16:40 <Son_Goku> it's pretty tough to juggle all the notifications sent as it is
15:16:53 <Son_Goku> and some of them simply just aren't sent, so I'd rather err on the side of caution here
15:17:25 <mhroncok> there are packages "maintained" by 10 nonresponsive maintainers
15:17:34 <zbyszek> mhroncok: but if the process is running again, this would be just a few weeks more. I think that's acceptable, especially that we're starting the process again after a long break.
15:17:46 <nirik> well, if there's 10 maintainers perhaps all 10 think someone else will take it...
15:17:59 <mhroncok> zbyszek: but the package won't be orphaned, it will not run again until somebody notices
15:18:03 <tyll> mhroncok, IMHO the problem with nonresponsive maintainers needs to be fixed by removing the non-responsive maintainers from all packages
15:18:30 <zbyszek> mhroncok: You have a point. So maybe only do the reassignment if the package was committed to within last 6 months or so?
15:18:36 <Son_Goku> alright folks, I gotta jet for a few minutes
15:18:41 <Son_Goku> I'll be back in ~15 minutes or so
15:18:51 <Son_Goku> bye
15:19:02 <zbyszek> I.e. orphan if package is "not alive", and reassign to last maintainer otherwise?
15:19:09 <mhroncok> zbyszek: anywat the policy says somehting. I'll gladly try to help here, but we need to be on the same page of what supposed to happen
15:19:16 <tyll> zbyszek, if the co-maintainers are inacurate, then it should be fixed instead of working aroud it IMHO
15:19:58 <mhroncok> "Orphan packages will be retired if they remain orphaned for six weeks."
15:20:15 <bowlofeggs> we've been on this topic for 15 minutes now - do we want to keep going, or move discussion back tot he ticket?
15:20:17 <tyll> mhroncok, IMHO the hard part of the current situation is that nobody knows if co-maintainers are notified when a package is orphaned (I believe they are not)
15:20:18 <mhroncok> if you feel that this is too bad, than fine, but change it
15:20:24 <zbyszek> Let's continue.
15:20:27 <mhroncok> tyll: they are not
15:20:39 <tyll> therefore before surprising everyone, it should be properly communicated before retiring on a large scale
15:20:48 <mhroncok> agreed
15:20:51 <zbyszek> Yes, I think this is a requiremnet.
15:20:54 <mhroncok> (and other want to mvoe on)
15:20:58 <mhroncok> *others
15:21:02 <sgallagh> Can we get an auto-mailer out once a week to any package that is orphaned which has comaintainers?
15:21:06 <jsmith> "It's OK to be disappointed, it's not OK to be surprised!"
15:21:08 <sgallagh> That can't be too hard, can it?
15:21:39 <nirik> the hard part is telling which are retired already I think...
15:21:46 <tyll> what nirik wrote
15:22:02 * bowlofeggs misses pkgdb
15:22:03 <zbyszek> nirik: why? Just look for dead.package in dist-git?
15:22:08 <tyll> it is really slow to figure out which packages are only orphaned currently
15:22:12 <mhroncok> nirik: I have a code for that
15:22:36 <nirik> zbyszek: sure, but thats a pretty heavy query
15:22:54 <zbyszek> nirik: but it runs once per week, no?
15:22:59 <mhroncok> my idea was that the "executioner" (me?) would keep sending e-mail (once a week maybe?) with the plan for next week, CCing all the comaintainers and dependent comaintainers
15:23:13 <nirik> that sounds good to me.
15:23:18 <mhroncok> the period can be longer
15:23:23 <bowlofeggs> mhroncok: i would recommend making the executioner be cron ☺
15:23:31 <mhroncok> bowlofeggs: sure, I meant for now
15:23:34 <bowlofeggs> ack
15:23:41 * sgallagh makes a note to buy mhroncok a black hood for Christmas.
15:23:46 <bowlofeggs> hahaha
15:23:47 <tyll> do we first want to re-assign the currently orpphaned packages or not? If not, I can probably get the old report running again, but it affects a lot of packages
15:23:50 <mhroncok> and if people get suprised by having a package retired, well they can unretire it
15:24:13 <sgallagh> Honestly, I'd actually prefer we just go ahead and do the retirement.
15:24:25 <sgallagh> If the package is actually cared-about, they have what, two weeks to unretire for "free"?
15:24:32 <bowlofeggs> oh that's true
15:24:38 <mhroncok> sgallagh: exectly
15:24:40 <sgallagh> Then after that, if it needs to come back, I'd be happy with the re-review
15:24:41 <tyll> sgallagh, unretiring is an awefule manual releng process
15:24:42 <bowlofeggs> you only have to do the re-review if it's been retired for a while
15:24:50 <tyll> (AFAIK)
15:25:03 <mhroncok> ackages that are retired for Rawhide for more than two weeks need to be reviewed again before they can be un-retired. This is also true for EPEL-only packages.
15:25:06 <bowlofeggs> so much of releng is manual now, due to pkgdb retirement :/
15:25:20 <zbyszek> mhroncok: can you wait let's say 3 weeks before retiring (with weekly email)? So that maintainers have more than a week to respond?
15:25:26 <mhroncok> if you give me rights to do manual unretirement, I'm willing to do that as well
15:25:35 <mhroncok> zbyszek: sure
15:25:40 <mhroncok> couple weeks are OK
15:25:40 <sgallagh> mboddu: Can you comment on what unretirement entails?
15:25:48 <mhroncok> the problem here is that we have packages orpahned for years
15:25:50 <nirik> needs unblocking in koji
15:25:55 <nirik> which requires koji admin
15:26:09 <zbyszek> proposal: give right to mhroncok to reassing ownership of packages and unretire packages (koji admin and whatnot)
15:26:18 <tyll> it also needs some checks to ensure that the request is valid
15:26:26 <bowlofeggs> i wish src.fpo had features to do this stuff
15:26:30 <mboddu> Also, reverting the changes in dist-git
15:26:31 <bowlofeggs> that would be real nice
15:26:40 <tyll> bowlofeggs, you mean it would be pkgdb?
15:26:46 <nirik> I don't think we need to worry about unretirement unless it becomes a problem.
15:26:47 <bowlofeggs> tyll: haha yep
15:26:47 <mhroncok> tyll: :D
15:27:22 <mhroncok> nirik: right, i don't think it will be an unretirement zombie apocalypse
15:27:34 <zbyszek> nirik: with this number of packages, let's be "forward looking" and assume there will be a problem ;)
15:28:06 <mhroncok> we are at ~500
15:28:07 <bowlofeggs> so what do we need to figure out today?
15:28:21 <mboddu> In short, koji unblock, dist-git revert of retirement commit, giving the package to the requestor, verifying the unretirement  BZ request
15:28:29 <bowlofeggs> sounds like mhroncok is willing to take the lead on writing some code to help automate this
15:28:29 <tyll> three months ago about 1000 pkgs were candidates to be retired
15:28:48 <bowlofeggs> whoah that's so many
15:28:52 <mhroncok> tyll: so we assume people took care of them becasue of the announcment?
15:29:24 <nirik> sure they did! :)
15:29:38 <zbyszek> mhroncok: you forgot to put a smiley
15:29:39 <tyll> mhroncok, there were a lot tickets to get pacakges at releng
15:30:05 <mhroncok> nice
15:30:10 <bowlofeggs> we've now been on this topic for 25 minutes - do we want to keep going or move discussion back to the ticket?
15:30:23 <zbyszek> bowlofeggs: I think we're 95% there
15:30:38 <bowlofeggs> what remaining question(s) do we want to answer in this meeting?
15:30:58 <zbyszek> I want an answer to my proposal above, i.e. giving permissions to mhroncok
15:30:58 <mhroncok> are we aiming at policy change or not?
15:31:11 <tyll> to me it is still unclear if we want to re-assign orphaned packages first to co-maintainers or not
15:31:23 <mhroncok> i.e. is it reassign to comaintainer or retire (with a lot of warnings perhaps)?
15:31:54 <nirik> I guess I don't object to adding mhroncok as a koji admin, but I am against changing the process without a plan.
15:31:54 <sgallagh> I vote retire.
15:32:07 <zbyszek> Retiring is in agreemnt with the policy, so I don't think we actually need to change any poliyc.
15:32:24 <zbyszek> I vote retire too.
15:32:30 <mhroncok> unless you want reassigning and in that case a policy change is IMHO required
15:33:00 <zbyszek> No, reassign-with-warnings sounds perfectly OK and easier to implement.
15:33:10 <bowlofeggs> ok let me try to state the remaining questions: 0) vote on zbyszek's proposal (can you restate it?), 1) re-assign vs. retire immediately (is this the same as "policy change"?)
15:33:12 <nirik> hopefully any packages with active comaintainers would take the package in the 3 weeks of reports before they retire.
15:33:46 <sgallagh> bowlofeggs: The current policy says "retire".
15:34:21 <maxamillion> I just lit the microwave on fire on accident ... brb
15:34:27 <sgallagh> Let's make sure those reports get sent to individual package-owner@ aliases?
15:34:42 <mhroncok> it doesn't say "retire immediately" so waiting 3 weeks after announcement is perfectly fine
15:34:46 <Pharaoh_Atem> back
15:34:53 <mhroncok> maxamillion: be safe
15:34:54 <bowlofeggs> i see a lot of people voting to keep the policy the same as it is (retire) - any objectors?
15:35:23 <tyll> sgallagh, my reports went to the FAS@fpo address to avoid people getting too many copies of the same e-mail
15:35:49 <zbyszek> proposal (1): The policy to retire packages after six weeks of being orphaned is reaffirmed. At least three warnings with one-week intervals will be sent out to co-maintainers before retiring.
15:35:53 <zbyszek> proposal (2): mhroncok gets koji admin rights to be able to drive the retirement process and any unretirements if necessary.
15:35:57 <sgallagh> tyll: My thought was that the owner@ address is a handy reply-all so they can sort out who would take it.
15:36:05 <sgallagh> I'd recommend suggesting that in the email sent out
15:36:19 <sgallagh> +1/+1
15:36:20 <nirik> +1 to 1... 2... I would prefer that be restated...
15:36:34 <sgallagh> nirik: Patch for prop 2?
15:36:41 <zbyszek> nirik: please restate then, I know nothing about the permission model here
15:37:01 <nirik> mhroncok is added as a release engineer to process unretirement requests (which are still the same process as now, file ticket, it gets checked, etc)
15:37:10 <mhroncok> (note that as a provenpackager, I can retire anything)
15:37:22 <tyll> sgallagh, the thing is, that the script also reports this for depending packages, i.e. if python2 is orphaned, python2-foo maintainers are notified as well - and also everyone who maintains somehting that requirs python-foo
15:37:35 <nirik> I want to avoid "unretirement process is talk to mhroncok" (which doesn't scale and is a single point of failure:)
15:37:43 <mhroncok> I also assume there will be more unorphan requests than unretire (and I cannot do either)
15:38:07 <sgallagh> nirik: I assume the proposal was "mhroncok is added to the list of people who can unretire"
15:38:12 <nirik> sure, or any requests you want to be trained up and do. ;)
15:38:27 <mhroncok> nice!
15:38:33 <mhroncok> works for me
15:38:33 <bowlofeggs> i'm +1 to proposal 1 and to nirik's restatement of proposal 2
15:38:43 <zbyszek> +1 to 1,
15:38:51 <zbyszek> +1 to nirik's restatement of proposal 2
15:38:51 <nirik> (hopefully mboddu agrees...)
15:40:10 <tyll> +1 to 1, and +0 for 2 (I think the idea is great but also I think it could be managed within releng instead of being decided by fesco)
15:40:13 <nirik> so where are we on votes?
15:40:16 <jsmith> +1 to 1 and to nirik's restatement of proposal 2
15:40:26 * bowlofeggs counts
15:40:57 <bowlofeggs> i see +5, +4
15:40:59 <maxamillion> +1 to nirik's restatement of proposal 2
15:41:08 <bowlofeggs> maxamillion: what's your vote on prop 1?
15:41:12 <maxamillion> +1 to 1
15:41:18 <bowlofeggs> and sgallagh?
15:41:27 <bowlofeggs> ok i think that's +6, +5
15:41:42 <sgallagh> I'm +1/+1 as above
15:41:51 <bowlofeggs> ok +7, +6
15:41:59 * bowlofeggs writes up two agreed's
15:42:18 <bowlofeggs> #agreed The policy to retire packages after six weeks of being orphaned is reaffirmed. At least three warnings with one-week intervals will be sent out to co-maintainers before retiring. (+7, 0, -0)
15:42:40 <bowlofeggs> #agreed mhroncok is added as a release engineer to process unretirement requests (which are still the same process as now, file ticket, it gets checked, etc) (+6, 1, -0)
15:42:45 <bowlofeggs> alright, ready to move on?
15:42:52 <zbyszek> ack
15:42:54 <Pharaoh_Atem> ack
15:43:07 <bowlofeggs> the next one is actually related:
15:43:10 <bowlofeggs> #topic #1973 FTBFS package are not being orphaned, nor retired
15:43:12 <bowlofeggs> .fesco 1973
15:43:13 <zodbot> bowlofeggs: Issue #1973: The FTBFS cleanup policy is not happening - fesco - Pagure.io - https://pagure.io/fesco/issue/1973
15:43:38 <bowlofeggs> do we have anything to decide on this that's separate than what we just discussed?
15:43:52 <bowlofeggs> mhroncok: ?
15:44:25 <mhroncok> it's similar
15:44:34 <mhroncok> nobody is doing it
15:44:41 <tyll> I guess here we need also a volunteer who does the notifications
15:44:49 <mhroncok> there ar eno remainderds, releng asked for a sciprt, but got me no feedback
15:45:14 <nirik> well, now that f29 is out the door, mboddu might have more time... but I could be wrong
15:45:20 <tyll> Also there need to be scripts to check if bugs are still wrongly open
15:45:43 <mhroncok> tyll: that would be helpful
15:46:11 <mhroncok> I mean i offer my help in this but there's nobody who would tell me what can I actually do
15:46:14 <nirik> the reminder sounds like it could just run as a cron
15:46:14 <zbyszek> tyll: there is a script for that
15:46:35 <zbyszek> ignatenkobrain wrote one that is even committed to the rel-eng repo iirc
15:47:13 <nirik> so basically this just needs test and added to cron? I can assist with that...
15:48:12 <ignatenkobrain> Hello
15:48:32 <zbyszek> nirik: that'd be great
15:48:32 <ignatenkobrain> There is script in releng repo
15:48:53 <nirik> yeah, will add it to my list... if all the scripts are done, should be pretty easy to just add a cron
15:49:00 <ignatenkobrain> https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-close-bugs.py
15:49:33 <bowlofeggs> #action nirik will add https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-close-bugs.py to cron
15:49:43 <bowlofeggs> cool, do we need anything else than adding that to cron?
15:49:56 <nirik> I don't think so...
15:49:58 <mhroncok> bugzilla weekly reminders
15:50:15 <mhroncok> https://pagure.io/releng/pull-request/7881
15:50:17 <zbyszek> This doesn't do the orphaning, right?
15:50:31 <mhroncok> no, just reminders
15:50:39 <nirik> yes, I was going to add both those... the cleanup script, then after that the weekly nag
15:51:26 <mhroncok> nirik: thanks
15:51:36 <bowlofeggs> cool, so sounds like we are ready to move to the next topic?
15:51:53 <jsmith> WORKSFORME
15:51:59 <zbyszek> +1
15:52:08 <bowlofeggs> #topic #2009 libsolv SONAME bump in stable
15:52:11 <bowlofeggs> .fesco 2009
15:52:12 <mhroncok> thank you all for this and sorry to steal your meeting ;)
15:52:13 <zodbot> bowlofeggs: Issue #2009: libsolv SONAME bump in stable - fesco - Pagure.io - https://pagure.io/fesco/issue/2009
15:52:23 <nirik> mhroncok: thanks for pushing it forward.
15:52:23 <bowlofeggs> this one actually already happened, but was on last week's agenda
15:52:37 <bowlofeggs> i guess we don't really need to discuss it, unless anyone has something to say?
15:52:45 <bowlofeggs> thanks mhroncok!
15:52:51 * jsmith has nothing further to add
15:53:03 <sgallagh> I don't think there's anything to say here. It followed the policy, but we (FESCo) made a mistake and didn't ensure that those depending on it were aware.
15:53:09 <sgallagh> Let's do better next time. The End.
15:53:13 <nirik> +1
15:53:13 <Pharaoh_Atem> +1
15:53:17 <zbyszek> +1
15:53:20 <bowlofeggs> cool, let's move on then
15:53:28 <bowlofeggs> #topic #2013 to strict rules for branches deletion alongside with norules for theirs creations
15:53:31 <bowlofeggs> .fesco 2013
15:53:33 <zodbot> bowlofeggs: Issue #2013: too strict rules for branches deletion alongside with norules for theirs creations - fesco - Pagure.io - https://pagure.io/fesco/issue/2013
15:53:35 * mboddu was in a standup, but I will work with nirik with cron and scripting work
15:53:47 <Pharaoh_Atem> wut?
15:53:53 <mhroncok> mboddu++
15:53:53 <zodbot> mhroncok: Karma for mohanboddu changed to 9 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:54:03 <Pharaoh_Atem> this topic title doesn't make sense, is this about making private branches deletable?
15:54:10 <bowlofeggs> ok that roofer just showed up, so i need someone to take over running the meeting for me for a few minutes
15:54:11 <Pharaoh_Atem> and allowing force pushes and what not?
15:54:14 <bowlofeggs> i sent the agenda to the fesco list
15:54:39 <mhroncok> Pharaoh_Atem: it's mostly when somebody pushed by accident, not to a fork but to the repo
15:54:47 <sgallagh> right
15:54:58 <zbyszek> proposal: let's wait for a volunteer to write the script, and revisit the ticket when we have an implementation proposal
15:55:03 <bowlofeggs> i actualyl did this in the bodhi repo last week
15:55:05 <bowlofeggs> it sucked!
15:55:07 <bowlofeggs> hahaha
15:55:09 <nirik> zbyszek: +1
15:55:11 <bowlofeggs> i made a 3.11 branch and now it's permanent
15:55:13 <bowlofeggs> hahaha
15:55:16 <bowlofeggs> zbyszek: +1
15:55:27 <Pharaoh_Atem> I've done that before myself too
15:55:33 <Pharaoh_Atem> it sucks when it happens :(
15:56:02 <mhroncok> happened to em as well in a bash for loop, so i've pushed to 8 packages at once :(
15:56:09 <bowlofeggs> oh man
15:56:11 <bowlofeggs> hahah
15:56:22 * zbyszek has opened a fcNN branch, and even opened a releng ticket to get it deleted, but got a reply that fNN branches cannot be deleted
15:56:33 <bowlofeggs> jsmith, sgallagh, maxamillion, tyll: vote on zbyszek's proposal?
15:57:55 <tyll> IMHO we can also allow the procedure and sanction manual cleanups by releng
15:58:25 <sgallagh> +1, I guess
15:58:28 <bowlofeggs> tyll: they can't realistically take the time to do it, and manual cleanup is also very risky (error prone)
15:58:29 <zbyszek> tyll: releng does not want to do the checks manually, which is totally understandable
15:58:31 <nirik> I really want to avoid releng spending a lot of time on this... they have enough to do
15:58:59 <bowlofeggs> there is legal obligation here, i think we need a well tested script
15:59:07 <bowlofeggs> it's deleting data after all
15:59:23 <bowlofeggs> i think we are up to +4
15:59:46 <tyll> bowlofeggs, if the branch is merged it is for me easier to see this in a git by hand to be sure that I have the right command to verify this
16:00:27 <bowlofeggs> tyll: keep in mind that you also have to verify in koji's data
16:00:47 <bowlofeggs> at least in some cases
16:00:50 <tyll> bowlofeggs, if the branch is merged, then nothing expect the name of the branch is going to be deleted
16:00:57 <bowlofeggs> true
16:01:11 <tyll> bowlofeggs, yes, I would not check that manually...
16:01:50 <bowlofeggs> i still think releng doesn't have an incentive to do this manually
16:02:03 <bowlofeggs> it's manual work and the payoff is just to remove a branch that is at worst annoying
16:02:18 <bowlofeggs> there's not a serious problem with these branches remaining
16:02:30 <bowlofeggs> so imo does not justify dangerous and manual work
16:02:32 <mhroncok> would it mae sense to somehow obfuscate branch creation instead?
16:03:15 <mhroncok> to prevent the accidents I mean
16:03:28 <tyll> bowlofeggs, ok, I am also happy with waiting for a volunteer
16:03:33 <bowlofeggs> ok i need to go talk to the roofer for real now - someone needs to run the meeting for a few min until i can get back
16:03:42 <zbyszek> bowlofeggs: I'll take over
16:04:44 <zbyszek> jsmith, sgallagh, maxamillion ?
16:05:04 <sgallagh> zbyszek: What am I being asked?
16:05:33 <zbyszek> For #2013, proposal: let's wait for a volunteer to write the script, and revisit the ticket when we have an implementation proposal
16:05:37 * sgallagh voted "+1, I guess" above
16:05:58 <zbyszek> You're right.
16:06:17 * zbyszek tallies the votes
16:07:10 <zbyszek> AGREED: we'll wait for a volunteer to write the script to do the checks, and revisit the ticket when we have an implementation proposal (+5, 0, 0)
16:07:15 <zbyszek> tyll: I counted you as +1
16:07:26 <tyll> zbyszek, yes
16:07:27 <zbyszek> OK to move on?
16:07:39 * nirik nods
16:07:49 <zbyszek> #topic #2003 Ursa Major (modules in buildroot) enablement
16:07:52 <zbyszek> https://pagure.io/fesco/issue/2003
16:08:19 <zbyszek> If that's OK, I'll paste part of the earlier conversaition with sgallagh and nirik in #fedora-devel
16:08:29 <Son_Goku> fine with me
16:08:52 <zbyszek> 14:54 < zbyszek> sgallagh: I'm rereading the dicussion, and I don't understand one thing: There were proposals
16:08:55 <zbyszek> (e.g. by nirik) to create a "builtroot" repo that would contain rpms used for building,
16:08:58 <zbyszek> including those from the default modules and some select non-default modules (i.e. those added
16:09:01 <zbyszek> by Ursa Major).
16:09:03 <zbyszek> 14:55 < zbyszek> So, my understaning is that this provides a set of rpms, in some specific versions
16:09:07 <zbyszek> 14:55 < zbyszek> But you also talk about allowing packages to build using a slightly older version of go compiler
16:09:10 <zbyszek> if they are incompatible with the latest version
16:09:12 <zbyszek> 14:56 < sgallagh> zbyszek: I never entirely understood what nirik was trying to say about the buildroot repo,
16:09:15 <zbyszek> honestly.
16:09:18 <zbyszek> 14:56 < zbyszek> I don't understand how those two things fit together (having one version of rpms and using older
16:09:21 <zbyszek> rpms during build).
16:09:23 <zbyszek> 14:56 < sgallagh> The point of Ursa Major is specifically to allow you to create a buildroot with non-default
16:09:26 <zbyszek> module streams so you can build something that has build-time-only dependencies on a package in
16:09:29 <zbyszek> a non-default stream.
16:09:32 <zbyszek> 14:57 < sgallagh> If it has a runtime dependency on a non-default stream, you must build it as a module with
16:09:35 <zbyszek> proper module deps.
16:09:37 <zbyszek> 14:57 < bowlofeggs> sgallagh, contyk: i moved ursa major to be last
16:09:39 <zbyszek> 14:58 < sgallagh> This is meant to handle the case like I described, where we might be shipping golang X as the
16:09:43 <zbyszek> default stream (and therefore in the default buildroot), but you want to ship a package that
16:09:46 <zbyszek> can only build with golang x-1.
16:09:48 <zbyszek> 14:58 < sgallagh> Since it doesn't need golang at *runtime*, we shouldn't force people to make that package into
16:09:51 <zbyszek> a module.
16:09:53 <zbyszek> 14:58 < zbyszek> sgallagh: So how does the package specify that it needs the non-defaul build stream?
16:09:57 <zbyszek> 14:58 < sgallagh> Right now, that is their only option.
16:09:59 <zbyszek> 15:00 < sgallagh> Umm, good question. I haven't had to do it myself, so I'll need to look that up
16:10:02 <zbyszek> 15:00 < nirik> the repo was an attempt to allow users to build things that take advantage of ursa-major without
16:10:05 <zbyszek> using our koji.
16:10:08 <zbyszek> Yikes, sorry for the formatting.
16:10:10 <zbyszek> If you stretch the window "just right", it looks OK ;)
16:10:15 <zbyszek> My current understanding it that nirik proposal is not workable, because it'd give just one repo with a specific set of packages, but UM is about allowing different packages to have deps on different non-default modules
16:10:33 <Son_Goku> yeah, that's my understanding of the situation too
16:10:45 <zbyszek> Hence, UM is incompatible with external builders that do not understand the module metadata.
16:10:53 * sgallagh nods
16:10:57 <Son_Goku> which is basically all of them, by the way
16:11:18 <nirik> yeah, bummer. :(
16:11:20 <mizdebsk> zbyszek, not correct, ursa-major allows configuring one global module set for use in all non-modular package builds
16:11:30 <sgallagh> Unfortunately, the Ursa Major devs are not around to ask.
16:11:40 <ignatenkobrain> IIUC, it is opposite
16:11:49 <ignatenkobrain> It pulls default streams into buildroot
16:11:59 <sgallagh> But I think what it basically does is offers a tool that allows you to request a custom buildroot (sort of like building against a side-tag)
16:12:06 <nirik> well, its changable right? just like buildroot overrides would be in a tradiational repo
16:12:21 <mizdebsk> sgallagh, no
16:12:23 <sgallagh> mizdebsk: Wait, really? That doesn't line up with what I've heard, I don't think
16:12:45 <mizdebsk> ursa major adds contents of some modules to koji build tags
16:12:49 <sgallagh> (if that's *not* what it's doing, then I guess I may not understand its purpose at all)
16:12:55 <mizdebsk> but there is still a single build tag for all packages
16:12:59 <jsmith> Is there any particular rush on this?  Can we wait another week and hopefully get more clarification?
16:13:18 <zbyszek> mizdebsk: so what you describe would be equivalent to having default-for-buildroot stream (like default streams are for runtime).
16:13:35 <sgallagh> contyk: Are you around?
16:13:36 <mizdebsk> zbyszek, yes, exactly
16:14:27 <zbyszek> mizdebsk: but that means that the examples that were given, like "older sphinx", "older go" as a build dep, are not possible?
16:14:32 <sgallagh> OK, so this would *only* be addressing the "default streams should end up in the buildroot" case.
16:14:37 <nirik> so there's no great hurry, but I think epel really would like us to enable this. :)
16:14:38 <sgallagh> Which is still important
16:14:50 <Son_Goku> unfortunately, unlike SCLs, modules require every single consumer of Fedora content to understand special metadata
16:16:00 <sgallagh> zbyszek: Yeah, sounds like I was wrong about it helping with that case.
16:16:06 * sgallagh sighs
16:16:17 <nirik> proposal: table this week, invite ursa-major devs next week to discuss.
16:16:28 <jsmith> +1 to nirik's proposal
16:16:59 <zbyszek> mizdebsk: but does UM require non-default modules to be tagged into the buildroot? Would be enought just get the default ones?
16:17:19 <contyk> o/
16:17:23 <contyk> .hello psabata
16:17:24 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
16:17:32 <contyk> sorry, that took much longer than I anticipated
16:17:51 <Son_Goku> and the big problem for me is that at as an external third-party packager (which I do a lot of), I literally can't consume and build on top of modular content
16:17:54 * nirik wants to know how it handles overlapping requests
16:18:22 <mizdebsk> zbyszek, UM adds some configurable set of module streams to ursine buildroot, technically it can be different set than default streams available for users
16:18:28 <nirik> thats why I thought the buildroot repo would be a good solution.
16:18:48 <zbyszek> Right, but do we *need* to make it different than default streams?
16:19:01 <Son_Goku> and while that alleviates some of the issues, my concerns are how this will propagate for runtime deps and for update repos
16:19:09 * zbyszek is worried that those different sets would just lead to confusion
16:19:15 <Son_Goku> what happens if a stream is switched (for whatever reason) in updates?
16:20:09 * contyk is reading the backlog
16:20:11 <nirik> the repo updates... but I don't know if that repo is workable...
16:20:26 <zbyszek> nirik: it sounds like it's workable
16:20:46 <zbyszek> If there's just one set of streams (however it is determined) at any given time, this can be turned into a repo
16:21:35 <zbyszek> So my question is basically this: do "ursine" packages need to depend on non-default streams for BR ever?
16:21:37 <contyk> so what are the questions?
16:21:39 <nirik> yeah, but what happens if userA asks for nodejs8 and userB asks for nodejs11?
16:21:58 <zbyszek> nirik: you mean packageA and packageB?
16:22:00 <nirik> I guess they are both there...
16:22:03 <contyk> note that UM doesn't work with default streams, even though I see it mentioned several times -- it has a completely separate config
16:22:17 <Son_Goku> zbyszek, it's entirely possible to do so
16:22:40 <Son_Goku> otherwise, as some people have mentioned, it defeats the point of modules :/
16:23:03 * Son_Goku wishes modules had just been implemented as independent repos...
16:23:04 <mizdebsk> nirik, both module streams would be added, the one with higher priority would "win"
16:23:07 <sgallagh> contyk: What we're suggesting is that the separate config should basically just say "use the default streams"
16:23:46 <zbyszek> Son_Goku: we could *set* a policy that ursine packages must be built only with the default streams, period.
16:23:56 <contyk> it's going to be the case in practice for most things, although not everything that is the default needs to be in the buildroot, and then there are building block-only modules
16:24:15 <sgallagh> zbyszek: Right, and I'm in favor of that for Fedora at this point
16:24:22 <Son_Goku> zbyszek, sure, and we'd need to enforce that default streams never change within a release
16:24:37 <zbyszek> Son_Goku: no, why?
16:24:38 <Son_Goku> because otherwise it gets really broken and screwy with merging info from GA and updates repo
16:24:44 <contyk> we don't need to enforce that
16:25:12 <Son_Goku> unless streams would handle upgrades properly, there's no way that'll make sense
16:25:19 <Son_Goku> it'll look like conflicts everywhere
16:25:23 <contyk> we discussed something similar just recently; you want to decide based on the nature of the change, not by the mechanism of delivery, e.g. it being a different stream
16:25:37 <sgallagh> Son_Goku: It's already a policy that default streams may not change within a release
16:25:44 <Son_Goku> sgallagh, ok
16:25:59 <Son_Goku> well, at least for now, doing this should keep things from being broken from my end
16:26:26 <sgallagh> Actually, that's not *entirely* true.
16:26:33 <sgallagh> A default may be *added* mid-release.
16:26:38 <sgallagh> But it cannot change
16:26:46 <Son_Goku> that's fine
16:26:53 <contyk> unless you're on rawhide
16:27:00 <Son_Goku> meh, rawhide always breaks itself
16:27:03 <sgallagh> Ah, point
16:27:16 <Son_Goku> I just expect rawhide to not work properly with modules anyway
16:27:50 <Son_Goku> as far as I can tell, no one has considered upgrade and transition strategies for streams and modules yet
16:27:57 <zbyszek> contyk: can you comment a bit on how this "separate config" should be created?
16:27:57 <nirik> thats a rosy outlook. :)
16:28:11 <Son_Goku> so for now, I fully expect all of that to have broken behavior
16:28:13 <sgallagh> Son_Goku: Untrue. We're discussing it quite actively
16:28:32 <sgallagh> Son_Goku: https://pagure.io/modularity/issue/108
16:28:36 <Son_Goku> hmm
16:28:49 <contyk> zbyszek: similar to how defaults are managed; I would expect the module maintainer to submit a config change if they wish to include their module in the ursine buildroot
16:28:57 * Son_Goku subscribes to it
16:29:27 <Son_Goku> anyway, at least insofar as adding support to the Open Build Service / openSUSE Build Service for modules, I'm blocked on https://github.com/fedora-modularity/libmodulemd/issues/101
16:29:49 <Son_Goku> it's been fun hitting that over and over with el8beta testing :/
16:30:30 <Son_Goku> sgallagh, but at least if ursa major + policies proposed by zbyszek are in place, I can be reasonably confident that I can still build packages properly for Fedora with my build system at work
16:30:46 <zbyszek> OK, could somebody write up a more-concrete proposal based on the discussion today in the ticket?
16:30:55 <zbyszek> contyk, mizdebsk, sgallagh?
16:30:57 <sgallagh> Son_Goku: That one is off-topic.
16:31:06 <contyk> I could though I'll have to read the whole backlog first
16:31:11 <contyk> as I missed almost all of it
16:31:19 <zbyszek> I mean offline
16:31:33 <contyk> ack, will do
16:31:41 <sgallagh> thanks, contyk
16:31:42 <nirik> I'd be in favor of enabling it, but I'd really like the buildroot repo tooling/proof that it will work first
16:31:49 <Son_Goku> ^
16:31:55 <zbyszek> OK, so my proposal is to move the discussion back to the ticket
16:31:58 <Son_Goku> is it possible to generate thin repos like that in pungi?
16:32:15 <Son_Goku> iirc, gathering packages is kind of wired into its repo creation process
16:33:16 <bowlofeggs> i'm back, baby
16:33:21 <bowlofeggs> zbyszek: +1 to moving back to ticket
16:33:26 <contyk> UM definitely adds some complexity
16:33:35 <bowlofeggs> i just read up and it sounds like we need input from the ursa devs anyway?
16:33:47 <Son_Goku> mizdebsk and contyk are ursa major devs, iirc
16:33:50 <contyk> what input do you need? perhaps I could answer
16:33:55 <contyk> ah, no, I'm not
16:34:07 <contyk> but I know what it does and how
16:34:17 <mizdebsk> Son_Goku, i am not
16:35:06 <Son_Goku> actually, who _does_ work on it?
16:35:11 <zbyszek> #action contyk to write up a summary in the ticket
16:35:14 <bowlofeggs> factory2?
16:35:15 <Son_Goku> this thing has no commits: https://pagure.io/ursa-major
16:35:21 <Son_Goku> except for an import
16:35:23 <mizdebsk> yes, factory 2
16:35:46 <bowlofeggs> Son_Goku: whoah, what?
16:35:53 <Son_Goku> bowlofeggs, yep
16:35:53 <bowlofeggs> that can't be the thing being proposed, right?
16:36:04 <Son_Goku> it was borne out of the head of... something?
16:36:15 <bowlofeggs> well i guess that's a giant commit
16:36:17 <Son_Goku> but yeah, it looks like there's no history or indication of who develops it
16:36:22 <bowlofeggs> there's a lot there, but certainly doesn't look 'active'
16:36:36 <bowlofeggs> this is like how google does android
16:36:46 <Son_Goku> :'(
16:36:47 <contyk> it's mostly cqi, with mprahl and jkaluza also being involved at some point, I think
16:36:51 <bowlofeggs> +8300 lines
16:36:52 <contyk> but that repo sucks
16:37:23 <Son_Goku> tossing things over the wall is not cool 👎
16:37:28 <bowlofeggs> well in any case, antyhing else to discuss on this today?
16:37:36 <Son_Goku> I got nuttin'
16:37:42 <jsmith> We've already talked about this 25 minutes -- I think we just need to move this back to discussion on ticket/mailing list.
16:38:01 <zbyszek> #info we'll discuss this in the ticket again
16:38:03 <zbyszek> OK, let's move on.
16:38:14 <zbyszek> = Open Floor =
16:38:17 <pac23> hi
16:38:27 <zbyszek> Oh, sorry, one more thing
16:38:36 <zbyszek> = Next week's chair =
16:38:40 <zbyszek> Any volunteers?
16:38:45 <jsmith> I can take it...
16:38:53 <jsmith> I haven't chaired in a while
16:38:55 <zbyszek> #topic Next week's chai
16:38:57 <zbyszek> #undo
16:38:57 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fe4ff3a7290>
16:38:59 <zbyszek> #topic Next week's chair
16:39:25 <zbyszek> thanks jsmith
16:39:28 <zbyszek> #topic Open Floor
16:39:35 <pac23> hi
16:39:50 <pac23> do i recently began packaging,reviewing and all that
16:40:07 <pac23> about to be sponsored,and i am happy to join the effort
16:40:16 <tyll> pac23, welcome!
16:40:20 <jsmith> Welcome to the world of packaging, pac23
16:40:27 <pac23> i had some gsoc questions
16:40:30 <contyk> next week's chai sounds better
16:41:10 <zbyszek> pac23: I'm not sure if we can answer any gsoc questions here
16:41:19 <zbyszek> Is there anyone here who does?
16:41:23 <bowlofeggs> #info elections happen soon
16:41:38 <bowlofeggs> #info nominate your favorite person to FESCo https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
16:42:01 <sgallagh> I usually prefer to nominate people I have a grudge against ;-)
16:42:11 <Son_Goku> sgallagh, so me, then? :P
16:42:27 <sgallagh> haha
16:42:29 <bowlofeggs> sgallagh: lol
16:42:34 <zbyszek> #info Nomination period is now open. The period ends on 2018-Nov-28 at 23:59:59 UTC.
16:42:39 <bowlofeggs> sgallagh: that's why i nominated jcline, but we aren't supposed to say that out loud
16:42:40 <pac23> zbyszek i just want to know where i can find more stuff related to core fedora development,where i could learn more about it before gsoc begins,i dont want to repeat last year and do want to be selected this year
16:43:08 <jcline> Hmrph
16:43:10 <zbyszek> pac23: please write to fedora-devel. This is not the right forum ofr this.
16:43:21 <pac23> i did write there never got a response
16:43:37 <pac23> i guess its too early for gsoc,but its never too early for gsoc
16:43:50 <bowlofeggs> pac23: fesco isn't itself involved with gsoc (this is fedora's engineering steering committee)
16:43:51 <sgallagh> pac23: email bex@fedoraproject.org
16:44:00 <bowlofeggs> pac23: i would recommend contacting the commops group
16:44:02 <jsmith> Yeah, gsoc isn't really a FESCo thing.
16:44:04 <bowlofeggs> or bex :)
16:44:32 <Son_Goku> jcline, if it makes you feel better, I like you :)
16:44:35 <bowlofeggs> pac23: https://docs.fedoraproject.org/en-US/commops/
16:44:58 <zbyszek> OK, anything else? bowlofeggs do you want the microphone back?
16:45:02 <bowlofeggs> zbyszek: sure
16:45:08 <pac23> okay thank you for the info bowlofeggs sgakkag zbyszek
16:45:18 <bowlofeggs> i'll close the meeting in 60 s if there's nothing further
16:46:18 <bowlofeggs> #endmeeting