17:04:15 <zbyszek> #startmeeting FESCO (2023-02-07)
17:04:15 <zodbot> Meeting started Tue Feb  7 17:04:15 2023 UTC.
17:04:15 <zodbot> This meeting is logged and archived in a public location.
17:04:15 <zodbot> The chair is zbyszek. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:04:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:04:15 <zodbot> The meeting name has been set to 'fesco_(2023-02-07)'
17:04:16 <zbyszek> #meetingname fesco
17:04:16 <zodbot> The meeting name has been set to 'fesco'
17:04:16 <zbyszek> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, music, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:04:16 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mhayden mhroncok music nirik sgallagh zbyszek
17:04:18 <zbyszek> #topic init process
17:04:21 <zbyszek> Sorry, I lost track of time.
17:04:24 <zbyszek> .hello2
17:04:25 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
17:04:27 <sgallagh> .hi
17:04:28 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:04:29 <jonathanspw> .hi
17:04:31 <zodbot> jonathanspw: jonathanspw 'Jonathan Wright' <jonathan@almalinux.org>
17:04:31 <Eighth_Doctor> .hello ngompa
17:04:34 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:04:35 <music[m]> .hello music
17:04:37 <zodbot> music[m]: music 'Benjamin Beasley' <code@musicinmybrain.net>
17:04:39 <carlwgeorge> .hi
17:04:40 <nirik[m]> morning everyone
17:04:40 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
17:04:54 <decathorpe> .hi
17:04:55 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
17:05:02 <Eighth_Doctor> evening/morning/afternoon (who knows when you're on a plane?)
17:05:47 <decathorpe> it's dark outside, so it could be either
17:05:48 <mhroncok> .hello churchyard
17:05:49 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:05:50 <zbyszek> Eighth_Doctor:  just look outside, but be careful which direction
17:06:01 <zbyszek> We have quorum. Let's start.
17:06:06 <zbyszek> #topic #2934 Restore Provides: singularity to apptainer packaging
17:06:06 <zbyszek> .fesco 2934
17:06:07 <zodbot> zbyszek: Issue #2934: Restore Provides: singularity to apptainer packaging - fesco - Pagure.io - https://pagure.io/fesco/issue/2934
17:06:27 <DrDaveD> .hi
17:06:28 <zodbot> DrDaveD: Sorry, but user 'DrDaveD' does not exist
17:07:07 <zbyszek> DrDaveD: use .hello <fasid>
17:07:15 <nirik[m]> this is a tough one, and not sure what to decide. ;(
17:07:27 <DrDaveD> .hello dwd@fedoraproject.org
17:07:28 <zodbot> DrDaveD: Sorry, but user 'dwd@fedoraproject.org' does not exist
17:07:31 <DrDaveD> .hello dwd
17:07:32 <zodbot> DrDaveD: dwd 'Dave Dykstra' <dwd@fnal.gov>
17:08:38 <davide> .hello dcavalca
17:08:39 <zodbot> davide: dcavalca 'Davide Cavalca' <davide@cavalca.name>
17:08:55 <zbyszek> So… I made the proposal to just add 'Provides:alternative-for(singularity)' and let the users make an explicit choice.
17:09:28 <music[m]> It seemed like the alternative-for(singularity) suggestion could be a sensible middle ground, but my familiarity with these packages is limited to skimming the discussion.
17:09:53 <decathorpe> I think that's an elegant solution for new installs. Not sure how to handle upgrades (or if that's even part of the question here, it's been so long :D )
17:10:14 * nirik[m] notes there was a comment overnight I haven't read yet
17:10:20 <carlwgeorge> apptainer-suid obsoletes singularity to handle the upgrade path
17:10:53 <DrDaveD> Also consider the case of people who have automated scripts for installing packages, such as building containers.  It's not always an interactive choice.
17:11:10 <zbyszek> decathorpe: IIUC, the ticket doesn't ask us to handle upgrades.
17:11:16 <mhroncok> I don't understand why "upgrading from singularity" and "installing singularity" should behave differently :/
17:11:22 <decathorpe> Even then, they should probably be aware that there might be two options, and update their scripts accordingly.
17:11:36 <zbyszek> decathorpe: yeah, just what I wanted to write ;)
17:12:17 <carlwgeorge> mhroncok: incompatible changes were done across all fedora and epel branches without a change proposal or epel incompat process, so it's all trying to retroactively clean things up
17:12:31 <Eighth_Doctor> zbyszek: how is that materially different from `Provides`+`Conflicts `sif-implementation`?
17:12:36 <music[m]> decathorpe: Right, if both choices have diverged in important, some people’s scripts are going to break no matter what.
17:13:23 <jonathanspw> I don't think singularity-ce has diverged *yet*.
17:13:24 <zbyszek> Eighth_Doctor: because dnf shows an error and says: you pick.
17:13:35 <nirik[m]> I like the alternate-for idea...
17:13:52 <carlwgeorge> jonathanspw: right, although they have said they plan to (hopefully in a new major version)
17:14:05 <Eighth_Doctor> which is what we want, don't we?
17:14:07 <music[m]> https://pagure.io/fesco/issue/2934#comment-839521 claims that both have diverged or plan to diverge
17:14:26 <Eighth_Doctor> also, when did we get support for zypp-style magic provides?
17:14:27 <carlwgeorge> zbyszek: i really like the "you pick" approach
17:14:33 <DrDaveD> I don't think that either side has diverged in significant ways at this point, either apptainer-suid or singularity-ce.  No more than what one would expect during normal package upgrades.
17:14:41 <jonathanspw> carlwgeorge: yeah, but for argument's sake at that point a proper version lock could happen.  non-diverged apptainer is much older I believe whereas singularity-ce is current and up to date and non-diverged as of yet.
17:14:59 <Eighth_Doctor> honestly, I prefer "you pick"
17:15:12 <jonathanspw> Seems the best way forward.
17:15:20 <Eighth_Doctor> I don't want us to have an opinion on this, given how ugly the discussion has been :(
17:15:39 <Eighth_Doctor> it's one thing to have opinions about the distro, but quite another to have opinions about upstreams
17:15:44 <jonathanspw> DrDaveD: what about the 2 items that dctrud mentioned in the latest update at https://pagure.io/fesco/issue/2934
17:15:51 <jonathanspw> seems like pretty large points of divergence and feature removal
17:15:55 <Eighth_Doctor> and I'm not a huge fan of getting in the middle of the singularity squabble
17:17:11 <Eighth_Doctor> to be honest, i don't think we have a real mechanism for this
17:17:13 <DrDaveD> I disagree, they are very minor, and do not affect most users. Those were required by the Linux Foundation because
17:17:18 <mhroncok> we don't
17:17:28 <mhroncok> but the alternative-for thing is close
17:17:46 <Eighth_Doctor> problems like this are pretty rare, and usually the community sorts itself out long before they reach us
17:17:47 <nirik[m]> but not 100%... as it doesn't do upgrades right?
17:18:09 <DrDaveD> The Fedora package rename process says nothing about the existence of forks, only of compatibility.
17:18:13 <sgallagh> mhroncok: Do we have documentation on `alternative-for()` or is it just a virtual provides/requires?
17:18:18 <jonathanspw> nirik[m]: there's an obsoletes in place to handle the upgrades
17:18:25 <sgallagh> (Is it a special syntax?)
17:18:40 <jonathanspw> well sort of, anyway.  it points to apptainer-suid which still is missing some features.
17:18:48 <mhroncok> Stephen Gallagher: I don't think we have documentation for it
17:18:56 <mhroncok> and it's just a virtual provides
17:19:01 <nirik[m]> jonathanspw: but it doesn't handle them the same way. it does not ask which one you want...
17:19:18 <decathorpe> documentation? just read the source code :)
17:19:27 <zbyszek> Upgrades are currently handled, and I don't think we want to revisit that answer.
17:19:51 <carlwgeorge> the original updates required config changes to preserve existing some behavior.  it's now handled by a complicated %posttrans scriptlet.
17:21:43 <zbyszek> So… what options do we have?
17:21:54 <zbyszek> 1. alternative-for()
17:21:56 <zbyszek> 2. do nothing
17:21:59 <zbyszek> 3. ???
17:22:17 <sgallagh> 3. Pick one of the forks and kick the other out of Fedora
17:22:21 <mhroncok> 3. put the provides to A
17:22:22 <mhroncok> 4. put the provides to B
17:22:22 <mhroncok> 5. put the provides to both
17:22:23 <sgallagh> (Not recommending, just noting it's an option)
17:22:32 <Eighth_Doctor> does alternative-for() do anything?
17:22:39 <mhroncok> let's vote in this roder?
17:22:43 <mhroncok> *order
17:23:04 <mhroncok> Proposal: All singularity forks use Provides: alternative-for(singularity)
17:23:13 <sgallagh> Hold on
17:23:18 <Eighth_Doctor> iirc, magic provides is a zypper thing, and I don't recall us putting it in DNF
17:23:24 <mhroncok> holding on
17:23:32 <carlwgeorge> Eighth_Doctor: https://pagure.io/fesco/issue/2934#comment-836095
17:23:32 <sgallagh> Just for clarification, all of these are options to address dnf install singularity, right?
17:23:40 <sgallagh> We're not concerning ourselves with upgrades?
17:23:55 <mhroncok> I wonder how we ended up with 2 things both claiming to be singular :D
17:24:02 <mhroncok> Stephen Gallagher: we are not
17:24:16 <sgallagh> OK, I just wanted that to be clear before voting
17:24:21 <mhroncok> Conan Kudo: dnf (and dnf5) handles alternative-for()
17:24:24 <mhroncok> see my comment...
17:24:26 <carlwgeorge> mhroncok: as i understand it, the image format requires /usr/bin/singularity
17:24:31 <nirik[m]> +1 to mhroncok's proposal
17:24:33 <mhroncok> https://pagure.io/fesco/issue/2934#comment-836095
17:24:36 <Eighth_Doctor> oh yay, magic provides in DNF :o
17:24:46 <Eighth_Doctor> okay then
17:25:01 <sgallagh> +1 for option 1
17:25:08 <decathorpe> +1 for Provides: alternative-for(singularity)
17:25:10 <DrDaveD> mhroncok: singularity-ce was a fork of singularity.  The singularity-ce package has never used the "singularity" Provides and they are not asking to.
17:25:26 <mhroncok> ok
17:25:46 <jonathanspw> DrDaveD of course singularity-ce would like "provides: singularity"
17:26:03 <jonathanspw> not attempting to use that was in good faith of trying to work together here
17:26:03 <Eighth_Doctor> then alternative-for(singularity) would effectively suggest only apptainer if only apptainer has it
17:26:10 <Eighth_Doctor> in that scenario, -1
17:26:12 <decathorpe> (I think mhroncok wanted to point out the irony of two projects that claim to be "singular")
17:26:18 <music[m]> +1 for the magic Provides
17:26:21 <Eighth_Doctor> lol
17:26:50 <DrDaveD> jonathanspw: The last post in the issue from dctrud says he is not asking for that.
17:27:11 <Eighth_Doctor> +1 for magic provides iff both apptainer and singularity-ce have it
17:27:17 <carlwgeorge> i think the suggestion is for both apptainer and singularity-ce to add `alternative-for(singularity)`
17:27:27 <zbyszek[m]> +1 to 1
17:27:35 <Eighth_Doctor> (to be clear, I don't like magic provides, but it exists in dnf, so...)
17:27:45 <nirik[m]> yes, that was the proposal...
17:28:02 <mhroncok> Conan Kudo: my proposal explicitly said so
17:28:22 <DrDaveD> Is FESCo OK about not following the Fedora rename process?
17:28:53 <sgallagh> As there is no consensus about which is the true successor, I think this is a reasonable compromise
17:29:04 <mhroncok> I am trying to count the votes but it's hard when everybody votes for different things
17:29:19 <nirik[m]> DrDaveD: in what particular?
17:29:35 <sgallagh> mhroncok: I didn't see any votes for other proposals at all
17:29:37 <DrDaveD> The rename process only talks about compatibility, it says nothing about forks
17:29:45 <Eighth_Doctor> +1 for mhroncok proposal
17:30:48 <mhroncok> Stephen Gallagher: some +1 my proposal, some +1 option 1 and some -1 my proposal but +1 the same things
17:30:49 <nirik[m]> yes, I don't think it applies in this case. This is a more complex case with onename-> multiple names... so, I am fine with doing this and not worrying about the rename policy.
17:30:50 <DrDaveD> Are people voting against the request for Provides: singularity on apptainer-suid because of a lack of compatibility?  Is it only because of a fork?
17:31:46 <DrDaveD> Seriously, please update the policy for future cases.
17:32:02 <jonathanspw> DrDaveD not sure how policy would've mattered, you broke it in 20x other ways anyway
17:32:14 <jonathanspw> But I agree, it should be updated regardless.
17:32:38 <mhroncok> Are we here to assign blame or decide a solution?
17:32:45 <nirik[m]> DrDaveD: I personally want to give the choice to the user... hey, this thing you were using has 2 options now. Look and decide which one you want. I think 'blessing' one thing takes that choice away from users... they may not know or investigate things.
17:33:13 <DrDaveD> If that's what FESCo wants, please write it down and make it public.
17:33:34 <mhroncok> make it public how?
17:33:35 <decathorpe> from a downstream / distro perspective, a fork and a rename are kind of the same thing (just done by different people), so I don't think we should prescribe a preference here, and give users the opportunity to choose for themselves
17:33:39 <mhroncok> the ticket is public
17:33:42 <mhroncok> this meeting is public
17:34:03 <DrDaveD> mhroncok: I mean make it a public written policy that people can search for
17:34:20 <music[m]> My perspective is that appears to be no consensus that either package is a compatible replacement, so we are considering this as an individual case rather than as an application of the renaming process. I don’t think any policy can cover all possible cases of multiple forks or renames when there is not a clear “winner.”
17:34:24 <jonathanspw> DrDaveD: the policy is public.
17:34:31 <music[m]> I keep leaving out words.
17:34:33 <jonathanspw> music[m]: fwiw singularity-ce is a 100% compatible replacement.
17:34:41 <nirik[m]> we could, but honestly this hasn't really ever come up before that I recall.. usually it gets sorted out upstream or all forks don't want the old name, etc.
17:35:07 <carlwgeorge> fwiw, the packaging guidelines have public sources that can take pull requests.  i don't see what's unclear about the current package rename policy, but if anyone has suggestions for wording please send them and the fpc will review.
17:35:16 <mhroncok> I see no point in writing a policy for a case that happens once in a decade
17:35:27 <mhroncok> and is usually solved by consensus between the package maintainers
17:35:45 <DrDaveD> Wow, I didn't realize that this situation was that unique
17:35:51 <mhroncok> and, what carlwgeorge says
17:36:07 <mhroncok> this is the first time I recall somebody approached fesco with this
17:36:32 <mhroncok> a silent consensus might happen more often
17:36:34 <nirik[m]> well, the rename review policy is fesco.... but same there, PR's considered
17:36:35 <Eighth_Doctor> yeah, I don't think this has happened recently
17:36:35 <Eighth_Doctor> or... ever?
17:36:41 <music[m]> jonathanspw: The `singularity-ce` maintainer seemed to say otherwise in https://pagure.io/fesco/issue/2934#comment-839521, but maybe I misunderstand. I don’t have independent knowledge on this one.
17:36:51 <mhroncok> (but of course, "once in a decade" was a hyperbole)
17:37:23 <sgallagh> The only other example of this I can think of offhand was MySQL/MariaDB
17:37:24 <Eighth_Doctor> the last situation where this might have happened was GNOME / MATE / Cinnamon, but everyone agreed upstream on how to handle that long before it got to us
17:37:29 <mhroncok> and docker
17:37:32 <jonathanspw> music[m]: singularity-ce hasn't diverged in a breaking way yet (but will in the future)
17:37:36 <sgallagh> Ah, right
17:37:41 <Eighth_Doctor> Docker was ~special~
17:37:50 <DrDaveD> carlwgeorge: the rename process has no mention about considering the existence of forks, it only talks about compatibility.  That's why I asked in my ticket for a judgement on whether or not the remaining two differences are considered compatibile enough.  It appear to be irrelevant.
17:38:48 <decathorpe> DrDaveD: well, process and policy can never account for 100% of edge cases
17:38:49 <carlwgeorge> the fork is irrelevant, it is about the compatibility.
17:39:15 <jonathanspw> DrDaveD: I think you're in a unique position as both a maintainer of apptainer and owner of the original "singularity" package which allowed what happened to happen.  In most cases the maintainer would (per policy) almost have to go with the compatible fork, OR version-lock the current branches and backport fixes, etc.  Short of that seeking fesco approval for non-compatible upgrades would have to be used.
17:39:17 <mhroncok> DrDaveD: the policies are meant as a rule of thumb. agreed-upon exceptions will always happen
17:39:32 <DrDaveD> Is it really?  There's been no discussion here about the two items of incompatibility.
17:40:16 <Eighth_Doctor> the problem at this point is we also have no experience understanding whether it resolves the incompatibility
17:40:27 * decathorpe wonders that happened to the vote that was going on
17:40:28 <Eighth_Doctor> we have no experts in singularity here that I know of
17:40:28 <carlwgeorge> my perspective is that if the level of compatibility is disputed, it's not "compatible enough" per the guidelines
17:40:42 <Eighth_Doctor> and the two maintainers of the two forks don't agree
17:40:47 <Eighth_Doctor> so what are we supposed to do?
17:40:54 <mhroncok> Fabio Valentini: I am waiting for the discussion to settle before goign back to the vote
17:41:25 <Eighth_Doctor> I'm going to have to pack up and go now
17:41:35 <mhroncok> let's take a step back
17:41:38 <Eighth_Doctor> my plane is about to land and internet service is going to be disconnected soon
17:41:41 <mhroncok> what we want to achieve here?
17:42:46 <sgallagh> The best end-user outcome
17:42:59 <DrDaveD> +1 to best end-user outcome
17:43:31 <zbyszek[m]> *my* goal is to do what's most reasonable for users.
17:43:47 <mhroncok> and we seem to agree that the alternative-for is the best thing for the users
17:44:00 <sgallagh> My understanding is that the end-user's experience will be disrupted by either of the two forks (either now or imminently, in the case of singularity-ce)
17:44:06 <jonathanspw> The best end-user outcome would be for singularity-ce to have the obsolete for old singularity since it is 100% compatible, then for users to decide between singularity-ce and apptainer SI guess through virtual provides.
17:44:19 <mhroncok> whether or not this is in line with the policy is not important
17:44:48 <decathorpe> "As a user, I want to install singularity. Since there are now two alternatives (of which fact I might or might not be aware of), I want to have the option to choose which of the alternatives to install."
17:45:02 <DrDaveD> I believe it is most reasonable for the users to not get a failure when they ask to install singularity, and to get the same package they get with an update, from the same project they always got it from.
17:45:21 <jonathanspw> DrDaveD: it's not the same project.  Stop trying to claim it is.
17:45:31 <DrDaveD> Of course it is
17:46:06 <mhroncok> I counted +6 but please somebody check that
17:46:12 <mhroncok> (I coutn as +1)
17:46:16 <mhroncok> * (I count as +1)
17:47:20 <mhroncok> Is there any FESCo member who would prefer a different outcome than the alternative-for approach?
17:47:32 <mhroncok> a.k.a do we need to vote for the other options?
17:48:35 <zbyszek[m]> There's six of us here, so unless somebody has a duality of opinion...
17:48:35 <sgallagh> It's the best option out of a lot of imperfect ones, IMHO
17:48:51 <mhroncok> (I'd be happy to support: "Maintainers can provide whatever they wont assuming it does not break other packages." as well, but not stronger than this.)
17:49:16 <zbyszek[m]> "want"
17:49:36 <nirik[m]> Yeah, it's not ideal, but I think it's the best we can do.
17:49:52 <mhroncok> I'm going to call it, unless there is a counterproposal
17:49:58 <sgallagh> "whatever they want" or "whatever their wont". Either works, though the latter is archaic
17:50:22 <mhroncok> wont was a typo
17:50:24 <mhroncok> want
17:50:25 <zbyszek[m]> Ah, nice.
17:50:34 <DrDaveD> Thank you for your serious consideration of my proposal.
17:50:35 <zbyszek[m]> Such a flexible language ;)
17:51:25 <mhroncok> :)
17:51:26 <mhroncok> DrDaveD: I am sorry this did not end up the way you wanted
17:51:37 <nirik[m]> DrDaveD: Thanks for being here and all the discussion in ticket. It's appreciated...
17:51:55 <mhroncok> #agree both packages add Provides: alternative-for(singularity) (+6,0,-0)
17:51:56 <sgallagh> The best possible outcome would be for the two forks to re-merge, of course. But that's well beyond FESCo's scope to facilitate
17:52:18 <DrDaveD> sgallagh: I agree
17:52:37 <mhroncok> ah, libreoffice and openofice.org :)
17:52:43 <mhroncok> s/openofice/openoffice/
17:52:58 * sgallagh sighs
17:53:01 <mhroncok> I was asked to take over chairing, but i need to dig out the agenda
17:53:46 <mhroncok> #topic #2950 FTBFS exception request for golang-helm-3
17:53:49 <mhroncok> .fesco 2950
17:53:50 <zodbot> mhroncok: Issue #2950: FTBFS exception request for golang-helm-3 - fesco - Pagure.io - https://pagure.io/fesco/issue/2950
17:54:07 <zbyszek[m]> https://pagure.io/fesco/issue/2950
17:54:49 <nirik[m]> think this got more time?
17:54:50 <sgallagh> Is there anything to do here?
17:54:58 <sgallagh> I'm not sure this really needed a vote, tbh
17:55:31 <mhroncok> yeah
17:55:41 <zbyszek[m]> Ok.
17:55:47 <mhroncok> I won't slay it. this will approved
17:55:57 <mhroncok> it isn't obvious from the ticket, how logn that exception should be active
17:56:06 <mhroncok> forever? 1 week?
17:56:16 <davide> I'm planning to get it updated as soon as the missing deps are imported
17:56:24 <davide> they're already reviewed and approved
17:56:43 <sgallagh> I'm good with offering up to 3 months and then revisiting if there's no movement.
17:56:51 <mhroncok> Davide Cavalca: I saw packagers that claimed the same thign and it never actually happened :(
17:57:01 <sgallagh> But it sounds like there's no reason to worry
17:57:15 <decathorpe> Davide Cavalca: what is blocking that work right now?
17:57:18 <mhroncok> anyway, I hope it just gets fixed and there is no need to figure that out
17:57:43 <davide> the packages in the BZs linked in the ticket need to be imported and built for rawhide
17:57:48 <davide> then I can update this and build it
17:57:54 <davide> I already have it working locally
17:57:55 <mhroncok> and I trust Davide Cavalca isn't trying to cheat the reaper
17:58:00 <decathorpe> so the thing that's missing is "fedpkg request-repo"?
17:58:08 <decathorpe> because you're not the submitter?
17:58:11 <davide> pretty much
17:58:34 <mhroncok> I saw packages waiting for that for months as well :)
17:58:38 <decathorpe> that's annoying :(
17:59:18 <nirik[m]> people get busy, things drop off radar. ;( Happens to everyone.
17:59:25 <mhroncok> count the votes in ticket and approve it or wait 1 day at approve it?
17:59:33 <mhroncok> tough choice
17:59:46 <decathorpe> I'm fine with either ;)
18:00:05 <mhroncok> assuming nobody casts -1 in the ticket now to make things more fun
18:00:27 <mhroncok> there are 5 votes in the ticket
18:00:33 <mhroncok> +1
18:00:59 <mhroncok> #agree golang-helm-3 won't be slayed this term (+6,0,-0)
18:01:01 <nirik[m]> +1 here
18:01:11 <sgallagh> Let's leave it for the remaining day, just in case someone who hasn't voted decides to nack it
18:01:19 <mhroncok> #undo
18:01:19 <zodbot> Removing item from minutes: AGREED by mhroncok at 18:00:59 : golang-helm-3 won't be slayed this term (+6,0,-0)
18:01:27 <mhroncok> ok
18:02:06 <mhroncok> #info kevin and churchyard both voted +1 in the meeting
18:02:16 <mhroncok> #topic Next week's chair
18:02:48 <zbyszek[m]> I might be out next week.
18:02:57 <decathorpe> I can do it - haven't done it in ages
18:03:19 <sgallagh> I'll be unavailable the week after next
18:03:45 <sgallagh> Fabio Valentini: If you want me to take it next week, I can do that if you want to take it the week I'm out
18:04:05 <decathorpe> sounds good to me
18:04:43 <mhroncok> #action Stephen Gallagher will chair the meeting next week
18:04:57 <mhroncok> #action Fabio Valentini will chair the meeting thew week after next
18:05:02 <mhroncok> #undo
18:05:02 <zodbot> Removing item from minutes: ACTION by mhroncok at 18:04:57 : Fabio Valentini will chair the meeting thew week after next
18:05:16 <mhroncok> #action Fabio Valentini will chair the meeting the week after next
18:05:26 <mhroncok> #topic Open Floor
18:05:32 <decathorpe> let me write this down so I don't forget ;)
18:05:34 <nirik[m]> I have one item...
18:05:46 <mhroncok> nirik: the floor is yours
18:06:54 <nirik[m]> Wanted to note/run by FESCo. There's a thread on devel about bootstrapping things... and it went into a discussion about changing macros in koji side tags. Currently, this is disallowed. We could allow maintainers to change any macro now if we wanted, or koji developers were open to the idea of some kind of allowlist where we could just allow bootstrap=1.
18:07:40 <nirik[m]> it was noted that maintainers can already change macros by just using %global in specs... but this is a bit less visible
18:07:40 <nirik[m]> koji does keep the history tho
18:07:48 <mhroncok> %globals in spec are transparent
18:08:01 <nirik[m]> I think it makes the bootstrapping case a bit better, as you just need a commit, then rebuilding twice.
18:08:18 <nirik[m]> instead of 2 commits, one with resetting things.
18:08:21 <mhroncok> you don't need to commit, but you need to flip the macro in the side tag
18:08:30 <decathorpe> isn't the macro name that does this _with_bootstrap?
18:08:54 <mhroncok> IMHO same amount of commands, but less transparent history
18:08:58 <nirik[m]> mhroncok: you need a commit unless you didn't build the last ver/release, right?
18:09:09 <nirik[m]> Fabio Valentini: yes
18:09:23 <mhroncok> but OTOH I think Perl folks set the perl_bootstrap macro in perl, boostrap the stack and than unset it, shich is arguably even worse
18:09:40 <nirik[m]> current case: commit and change bootstrap macros, bump release, rebuild, commit to unset macros, rebuild.
18:09:52 <mhroncok> nirik: bootsrap bconds change dist, if defined above Release:
18:10:18 <nirik[m]> sidetag macro case: set macro, rebuild, bump release, commit, rebuild.
18:10:22 <zbyszek[m]> I think allowing this would be nice...
18:10:28 <mhroncok> tl;dr I am not excited about the idea, but I won't fight it
18:10:38 <nirik[m]> yes, I know, but unless you didn't build that release koji will not let you reuse it.
18:10:41 <decathorpe> not sure what would happen to %autochangelog in this case
18:10:45 <zbyszek[m]> Can we continue the discussion on the mailing list though?
18:11:09 <mhroncok> I agree with mailing list
18:11:12 <nirik[m]> sure. I mostly wanted to bring it up in case there was a big outcry or desire to disallow it. ;)
18:11:24 <mhroncok> I guess nirik just wanted to let us know, right?
18:11:32 <nirik[m]> yes
18:11:36 <mhroncok> thanks
18:12:06 <mhroncok> there is also https://pagure.io/fesco/fesco-docs/pull-request/71 which might need more async discussion
18:13:09 <mhroncok> music: you wanted to bring something up?
18:14:10 <music[m]> Nah, I’m good. Just was going to say that I’m neither immediately opposed to nor overwhelmingly enthusiastic about the general idea of the bootstrapping thing.
18:14:40 <mhroncok> ok
18:14:48 <mhroncok> this is the end
18:14:55 <sgallagh> fin.
18:15:14 <mhroncok> suddenly everybody is typing
18:15:17 <zbyszek[m]> mhroncok: thanks for taking over.
18:15:27 <nirik[m]> I like that it avoids messing with complex / confusing with_bootstrap stuff in the spec... but yeah.
18:15:27 <decathorpe> FIN/ACK
18:15:47 <zbyszek[m]> FACK?
18:15:50 <nirik[m]> ICMP_HOST_UNREACHABLE
18:16:01 <mhroncok> #endmeeting