14:01:48 <dcantrell> #startmeeting FESCO (2020-08-26)
14:01:48 <zodbot> Meeting started Wed Aug 26 14:01:48 2020 UTC.
14:01:48 <zodbot> This meeting is logged and archived in a public location.
14:01:48 <zodbot> The chair is dcantrell. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:48 <zodbot> The meeting name has been set to 'fesco_(2020-08-26)'
14:01:48 <dcantrell> #meetingname fesco
14:01:48 <dcantrell> #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
14:01:48 <zodbot> The meeting name has been set to 'fesco'
14:01:48 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
14:01:51 <dcantrell> #topic init process
14:01:52 <zbyszek> .hello2
14:01:52 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
14:01:56 <King_InuYasha> .hello ngompa
14:01:57 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
14:01:58 <dcantrell> .hello2
14:01:58 <nirik> .hello kevin
14:02:00 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
14:02:03 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
14:02:34 <zbyszek> nirik: did something happen? You didn't say "morning".
14:02:42 <cverna> hello all
14:03:29 <dcantrell> hello everyone
14:03:33 <dcantrell> mhroncok said he'
14:03:36 <dcantrell> d be late to the meeting
14:03:42 <dcantrell> I count 5 here, so I guess we can proceed
14:03:45 <nirik> ha. morning. :)
14:03:56 <sgallagh> .hello2
14:03:57 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:04:04 <dcantrell> greetings, sgallagh
14:04:15 <sgallagh> Hello all
14:04:36 <dcantrell> so I did some digging through the queue and put some things on the agenda that I wanted us to talk about and see if we can make a decision or not.  some things seemed to have run out of energy and might just need a final discussion to close out.  we will see
14:04:46 <dcantrell> #topic #2454 Proposal: Force compiler / annobin updates to use side tags / rawhide gating
14:04:49 <zbyszek> dcantrell: famous last words
14:04:51 <dcantrell> .fesco 2454
14:04:52 <zodbot> dcantrell: Issue #2454: Proposal: Force compiler / annobin updates to use side tags / rawhide gating - fesco - Pagure.io - https://pagure.io/fesco/issue/2454
14:05:50 <zbyszek> My understanding is that pretty much everyone is for this, except the gcc maintainers who are somewhat reluctant.
14:06:29 <King_InuYasha> yep
14:06:33 <King_InuYasha> that's my understanding
14:06:37 <zbyszek> King_InuYasha: what if we downgraded "MUST" to "SHOULD"?
14:06:41 <King_InuYasha> no
14:06:50 <nirik> well, there's been no comment from them the last 2 weeks...
14:06:52 <zbyszek> If it breaks, we can tell the people "told you so"
14:07:22 <King_InuYasha> what do we do in that scenario beyond "told ya"?
14:07:29 <dcantrell> I think maintainers would be more open to this if the process was easier for them
14:07:31 <sgallagh> zbyszek: a SHOULD in a policy is equivalent to not writing that policy.
14:07:32 <King_InuYasha> because right now, I don't see what that would change
14:07:40 <dcantrell> I think  this feels like a lot of work on their end
14:07:56 <dcantrell> which might explain the reluctance
14:08:17 <nirik> yeah.
14:08:28 <dcantrell> for the record, I think this is a good idea
14:08:29 <nirik> perhaps someone would be willing to write/test the gating tests?
14:08:52 <decathorpe> hey, sorry for being late o/
14:08:55 <zbyszek> nirik: https://src.fedoraproject.org/rpms/gcc/pull-request/11
14:09:24 <King_InuYasha> bookwar took the tests I wrote for CentOS and ported it to Fedor
14:09:28 <King_InuYasha> *Fedora
14:10:33 <zbyszek> What is the current status with sidetags: how much slower would a build of gcc in sidetag be than straight in koji for rawhide?
14:10:53 <sgallagh> Why should it be any slower? It's the same builders, isn't it?
14:11:08 <zbyszek> There's some overhead to request the tag, etc.
14:11:09 <decathorpe> I think the only difference would be the initial wait time for newRepo
14:11:10 <nirik> there was slowness with newrepos for a while.
14:11:11 <dcantrell> yeah, I don't think it takes any longer, it's just more process
14:11:17 <dcantrell> ahh
14:11:17 <nirik> but as far as I know all those are solved.
14:11:22 <mhroncok> hey
14:11:56 <dcantrell> hi, mhroncok
14:12:21 <mhroncok> sorry for being late, had to walk the dogs after the previous meeting and it has ended exactly when this one started
14:12:27 <King_InuYasha> the waitrepo time is the same for chaining the build cycle
14:12:39 <King_InuYasha> since you have to wait for kojira to finish before it's available anyway
14:12:55 <nirik> sure, but for gcc maintainer, there's no wait or chain, just... gcc build
14:13:01 <mhroncok> annobin -- let's add the gating tests and them figure the best workflow for that whatever they want side tags or double builds?
14:13:16 <mhroncok> *and let them
14:13:17 <King_InuYasha> well, they won't merge the tests either
14:13:29 <decathorpe> but why
14:13:30 * nirik doesn't like forcing people to do things... it's much better to convince them.
14:13:31 <King_InuYasha> they don't like the idea of gating tests
14:13:39 <dcantrell> I agree with nirik
14:13:49 <King_InuYasha> that's why jakub implemented that weird thing in %check instead that's non-blocking
14:14:04 <King_InuYasha> we're in a no-win scenario right now
14:14:34 <mhroncok> it's hard to convince when they don't answer direct questions
14:14:55 <dcantrell> voting to the force the team to do something isn't going to work.  I think this ticket should be closed and a different approach taken for compiler gating
14:15:19 <King_InuYasha> we have no other approach to compiler gating
14:15:25 <decathorpe> dcantrell: why? this is what we have and it works for anybody else
14:15:33 <dcantrell> sorry, I mean a different approach to implement the change
14:15:45 <King_InuYasha> I'm fine with closing it if we can't realistically get a policy in place
14:15:56 <mhroncok> I agree that we should not force, but I don't think this works
14:16:14 <dcantrell> should this go through as a change proposal for F34?
14:16:18 <decathorpe> we can modify fedpkg to do the whole side tag thing internally if package == "gcc"
14:16:23 <zbyszek> I agree with what mhroncok said above: the gating test is the important part. Sidetags or not are the maintainer's choice.
14:16:23 <dcantrell> with an owner and people signed up to do the work?
14:16:28 <nirik> perhaps we could invite them to a meeting? or some other higher BW discussion?
14:16:37 <King_InuYasha> decathorpe: we could even just block gcc and llvm from direct merging if we must
14:16:45 <King_InuYasha> only allow them in from a side tag
14:16:55 <decathorpe> (that was supposed to be a joke bust sure :))
14:16:56 <King_InuYasha> but those are all painful options
14:17:27 * King_InuYasha is just tired of compiler being broken every release cycle because of annobin
14:17:36 <decathorpe> yes, just because the GCC maintainers dont want to cooerate?
14:17:37 <dcantrell> proposal: refocus 2454 on gating tests only for the compiler and annobin, followup with maintainers for next meeting
14:17:53 <King_InuYasha> dcantrell: so refocus to what it already is?
14:18:16 <dcantrell> remove "side tags" from the title
14:18:16 <King_InuYasha> btw, if a gating test is implemented, they *must* use side tags to merge because their builds will be rejected otherwise
14:18:23 <zbyszek> dcantrell: +1
14:18:28 <mhroncok> King_InuYasha: i don't agree
14:18:34 <zbyszek> King_InuYasha: no
14:18:38 <sgallagh> King_InuYasha: How do you figure?
14:18:59 <King_InuYasha> because at least based on what fedora CI folks told me, if a test fails, it's supposed to not be able to be tagged into the buildroot
14:19:09 <King_InuYasha> if it's a "gating test"
14:19:10 <mhroncok> the gating test will either pass and will go in
14:19:23 <mhroncok> or it will fail and they will need to rebuild in side tag
14:19:36 <King_InuYasha> right
14:19:51 <King_InuYasha> so that means the tests will force side tags anyway
14:19:55 <mhroncok> with what they are saying (it works 99% of the time) this will work
14:20:18 <nirik> so, there's mention of making it less dependent on each other... do we know how much thats happened? perhaps we could ask nickc about that?
14:20:21 <sgallagh> Right, it should mean that they only have to deal with a side-tag in the event that the gating test fails
14:20:27 <King_InuYasha> I'm fine with taking that statement at face value if the entire compiler stack is gated
14:20:31 <zbyszek> King_InuYasha: the side tags would only be needed if annobin needs to be rebuilt.
14:20:33 <King_InuYasha> llvm, gcc, annobin
14:20:48 <King_InuYasha> zbyszek: which is every time gcc and llvm change
14:20:55 <sgallagh> Question: would they be able to tag the succeeded-but-gated GCC into the side-tag?
14:20:58 <mhroncok> and if indeed it no longer needs to be built in sync, they won't need to use side tags ever
14:21:00 <King_InuYasha> nirik: that work has not been done
14:21:02 <sgallagh> Or would this necessitate rebuilding it again?
14:21:03 <mhroncok> but the check would still be in place
14:21:29 <nirik> well, it seems like it's ongoing in that bug...
14:21:33 <mhroncok> sgallagh: they could tag it in, but I am afraid bodhi won't allow the new joined update to have the same build in it
14:21:37 <King_InuYasha> nirik: there's a disagreement on the effectiveness of the approach
14:21:55 <decathorpe> well, the check is useful in and of its own, even if annobin isn't the cause of potential compiler issues
14:21:59 <mhroncok> sgallagh: but I'm not entirely sure
14:22:00 <sgallagh> mhroncok: Afraid because you don't know if it will or afraid because you DO know it will refuse it?
14:22:27 <mhroncok> sgallagh: I think it will refuse, but it's not confirmed
14:22:32 <King_InuYasha> dcantrell: I'm fine with your proposal, since I really don't care beyond them not breaking the distro every cycle
14:22:37 <King_InuYasha> so...
14:22:40 <King_InuYasha> dcantrell: +1
14:22:55 <sgallagh> mhroncok: Presumably gating tests can be rerun without doing another build
14:23:01 <King_InuYasha> sgallagh: they cannot
14:23:03 <sgallagh> If not... that's a bad situation
14:23:04 <mhroncok> sgallagh: yes, they can
14:23:09 <sgallagh> ...?
14:23:15 <mhroncok> sgallagh: by asking ci folks
14:23:24 <King_InuYasha> human overrides don't count :)
14:23:30 * sgallagh sighs
14:24:04 <sgallagh> I'd call that a blocker to gating for any package that takes a long time to build
14:24:06 * King_InuYasha mumbles something about zuul not being wired into the CI control mechanism in pagure to rerun pipelines
14:24:39 <dcantrell> ok, clearly plenty to discuss here and we need the package maintainers for the packages in question for further discussion
14:24:46 <dcantrell> I count +3 for my proposal, if that even matters
14:24:47 <sgallagh> agreed
14:25:04 * nirik looks back for the proposal
14:25:27 <sgallagh> Proposal: Invite the tools maintainers to next week's meeting, informing them that not showing up means they forfeit the right to an opinion.
14:25:33 <cverna> dcantrell: +1 from me
14:25:33 <King_InuYasha> sgallagh: +1
14:25:37 <decathorpe> you can have my +1 as well, side tags are an "implementation detail" and if they want to rebuild GCC in case of failure I don't care
14:25:44 <nirik> dcantrell: +1
14:25:46 <nirik> sgallagh: -1
14:25:53 <mhroncok> if we do nothing here, it will eventually be the same as approving the proposal
14:26:07 <nirik> mhroncok: yep
14:26:26 <mhroncok> I believe that defaulting for side tag is the right thing to do, but if they'd rather rebuild for the second time if the test fails, whatever
14:26:47 <dcantrell> so that's...
14:26:51 <sgallagh> 0
14:26:55 <mhroncok> the important bit is to get the gating test in place and my impression is that they don't want to do that for resons I don't understand
14:26:56 <sgallagh> (for dcantrell's)
14:27:04 <King_InuYasha> mhroncok: they don't like gating tests
14:27:22 <mhroncok> King_InuYasha: I have figured that out. but why, that's what I don't understand
14:27:39 <zbyszek> King_InuYasha: jakub said that they might not be effective (because no arm64 tests). But apart from that?
14:27:46 <sgallagh> My guess is that failure means a really long rebuild
14:27:49 <King_InuYasha> yes
14:27:53 <King_InuYasha> jakub said as much
14:28:06 <dcantrell> ok, shall we move on?  do I mark this with an agree or anything?  I don't know.
14:28:07 <King_InuYasha> he also implied that they expect this failure to happen often
14:28:14 <sgallagh> I'm not accepting the Nirvana Fallacy as a valid argument here
14:28:20 <decathorpe> sgallagh: only if they don't start the build in a side to begin with ...
14:28:50 <nirik> one other issue they could have with side tags is making the update at the end...
14:29:10 <nirik> dcantrell: I think we just try and discuss more and move on...
14:29:20 <dcantrell> nirik: noted
14:29:31 <dcantrell> let's move on to something less controversial
14:29:37 <dcantrell> #topic #2430 Send notifications of new FESCo tickets to fedora-devel (or daily/weekly digests)
14:29:40 <dcantrell> .fesco 2430
14:29:41 <zodbot> dcantrell: Issue #2430: Send notifications of new FESCo tickets to fedora-devel (or daily/weekly digests) - fesco - Pagure.io - https://pagure.io/fesco/issue/2430
14:29:51 <King_InuYasha> this still seems redundant
14:30:07 * mhroncok has reconnected, not sure if still receiving messages here
14:30:16 <King_InuYasha> welp
14:30:28 <decathorpe> I mean, if we send stuff for tickets that are not caused by anything that happened on the list first anyway, that's fine with me
14:30:42 <sgallagh> I thought we'd basically agreed not to bother with this and just do it manually when appropriate.
14:30:48 <nirik> sgallagh: +1
14:30:54 <zbyszek> sgallagh: +1
14:31:02 <King_InuYasha> sgallagh: +1
14:31:08 <decathorpe> +1, I thought so too
14:31:11 <zbyszek> (I'm not sure if we agreed so, but it sounds like a reasonable course of action.)
14:31:20 <cverna> +1
14:31:26 <dcantrell> yeah, I can't remember if we agreed or not, but I'm fine with that
14:31:27 <dcantrell> +1
14:31:31 * mhroncok has lost the connection apparently, what is the proposal?
14:31:33 <sgallagh> I don't think we voted on it, but I also don't recall anyone disagreeing with it
14:31:48 <sgallagh> I'll phrase it formally:
14:32:24 <sgallagh> Proposal: We won't automate this process. Instead, FESCo members will manually alert the fedora-devel list when appropriate.
14:32:32 <dcantrell> +1
14:32:46 <zbyszek> +1
14:32:49 <mhroncok> +1
14:32:53 <nirik> +1
14:33:33 <cverna> +1
14:33:54 <decathorpe> +1
14:34:14 <King_InuYasha> +1
14:34:26 <dcantrell> #agree (+8, 0, -0)
14:34:52 <dcantrell> way less discussion  :)
14:34:54 <dcantrell> #topic #2416 Update 3rd party repo policy
14:34:55 <dcantrell> .fesco 2416
14:34:56 <zodbot> dcantrell: Issue #2416: Update 3rd party repo policy - fesco - Pagure.io - https://pagure.io/fesco/issue/2416
14:35:45 <King_InuYasha> so that is about https://pagure.io/fesco/fesco-docs/pull-request/34
14:36:15 <zbyszek> I talked with aday, and I'll open a ticket to notify the Council once we're done with the process here, so that they are aware of the changes.
14:36:51 * nirik hasn't had a chance to review the latest.
14:36:57 * mhroncok neither
14:37:10 <dcantrell> ok, review and vote in the ticket again?
14:37:17 <mhroncok> is it ready for review?
14:37:25 <mhroncok> there seem to be some discussion going on still
14:37:51 <zbyszek> Yes, it's ready.
14:37:54 <dcantrell> oh I was looking at the fesco ticket
14:38:48 <cverna> let's vote in the ticket, I did not review the latest too
14:39:16 <sgallagh> Same
14:39:31 <dcantrell> ok, let's all vote in the fesco ticket then
14:39:41 <King_InuYasha> fine with me
14:39:54 <dcantrell> #topic #2410 RFE: Rename dist-git "master" branch to "rawhide"
14:39:55 <dcantrell> .fesco 2410
14:39:56 <zodbot> dcantrell: Issue #2410: RFE: Rename dist-git "master" branch to "rawhide" - fesco - Pagure.io - https://pagure.io/fesco/issue/2410
14:40:19 <King_InuYasha> there's nothing actionable there
14:40:32 <King_InuYasha> I'm cool with the idea of renaming the repo branch from master to rawhide
14:40:41 <dcantrell> that's what I thought.  in that case I will close the ticket
14:40:48 <mhroncok> +1 to close
14:40:51 <King_InuYasha> +1
14:40:54 * nirik hasn't had a chance to put together a change proposal, but plans to try
14:41:00 <decathorpe> I don't understand why we should approve the idea before they even submit a change proposal
14:41:02 <King_InuYasha> nirik: +1
14:41:25 <nirik> I think we may want to go with 'main' as thats what many places are doing.
14:41:41 <nirik> but thats something we could discuss with the change discussion.
14:41:51 <decathorpe> that makes no sense. rawhide should be rawhide, if we change it :)
14:41:59 <zbyszek> decathorpe: +1
14:42:10 <King_InuYasha> decathorpe: +1
14:42:12 <nirik> well, that makes it 'special'
14:42:15 <King_InuYasha> so?
14:42:33 <nirik> increased work on tooling and expectation of users.
14:42:34 <decathorpe> how so?
14:42:34 <King_InuYasha> if rawhide is the default branch, then it should be fine
14:42:37 <dcantrell> ok, I'll close it.  last one on my list:
14:42:40 <nirik> but I will stop now
14:42:44 <dcantrell> #topic #2452 F34 Self-Contained Change: Policy for Modules in Fedora and Fedora ELN
14:42:47 <dcantrell> .fesco 2452
14:42:48 <zodbot> dcantrell: Issue #2452: F34 Self-Contained Change: Policy for Modules in Fedora and Fedora ELN - fesco - Pagure.io - https://pagure.io/fesco/issue/2452
14:43:13 <decathorpe> meh ... what do we need to talk about here?
14:43:28 <dcantrell> I don't know.  I was going through all open tickets picking out things that are kinda sitting around
14:43:33 <dcantrell> is there anything to discuss here?
14:43:37 <dcantrell> does the ticket need to stay open?
14:43:39 <dcantrell> I don't know
14:43:53 * King_InuYasha is tired
14:44:10 <nirik> I think it's perhaps down to just voting... if all the feedback from the list is merged back in?
14:44:12 <sgallagh> I have answered the questions posed on the mailing list
14:44:16 <decathorpe> I think there were some votes in ticket already?
14:44:30 <sgallagh> (To the best of my ability)
14:44:31 <nirik> yep.
14:44:32 <decathorpe> though mine is a rather weak +1 ...
14:44:52 <zbyszek> sgallagh: since it's been clarified on the mailing list that this policy should only apply to ELN, can you adjust the text to make that clear? Current wording is misleading.
14:44:52 * nirik is +1, I guess I will add that to the ticket.
14:44:53 <cverna> yeah I voted in the ticket
14:45:01 <King_InuYasha> same
14:46:23 <sgallagh> zbyszek: I thought I had, but if you want to suggest better phrasing, please do
14:46:41 <zbyszek> Yeah, I'm rereading.
14:47:03 <dcantrell> I'll read over all of the updates and current proposal and vote in the ticket
14:47:17 <zbyszek> Yeah, same here.
14:47:20 <sgallagh> I think my vote should be obvious :)
14:47:40 <dcantrell> #topic Next week's chair
14:48:15 <dcantrell> anyone?
14:48:36 <zbyszek> I can do it.
14:48:41 <dcantrell> thanks!
14:48:50 <dcantrell> #action zbyszek will chair next meeting
14:49:01 <dcantrell> #topic Open Floor
14:49:17 <zbyszek> Quick q:
14:49:47 <zbyszek> the first ticket we discussed, about compiler side-tags, do we need to #action someone to restart the discussion with gcc maintainers?
14:50:08 <dcantrell> I asked that and got no response, so I didn't
14:50:12 <dcantrell> I'm ok taking that action
14:50:34 <decathorpe> dcantrell++
14:50:34 <zodbot> decathorpe: Karma for dcantrel changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:51:02 <zbyszek> dcantrell++, thanks
14:51:05 <dcantrell> np
14:51:18 <dcantrell> I've made notes for all of the tickets and was going to go through them after this meeting
14:51:40 <dcantrell> anything else from anyone?
14:51:51 <dcantrell> I know we're almost at an hour, sorry for that
14:52:14 <dcantrell> ok, with that I'm going call end of meeting
14:52:17 <zbyszek> dcantrell: the meeting is officially 2h, anything less is a bonus
14:52:26 <dcantrell> #endmeeting