I think what macros to allow in general is a complicated topic. But we can deal with a much narrower issue more quickly:

PROPOSAL: Packagers can set %_with_bootstrap macro in sidetags.

(And in general, for other macros, I think we should approve them one-by-one. At least for now, I don't see a good reason to allow arbitrary macros. This could quickly get messy.)

What would this workflow look like? Something like this?

• request side tag
• set _with_bootstrap macro to 1
• build everything that needs to be bootstrapped
• set _with_bootstrap macro to 0 (or remove it)
• build everything in non-bootstrap mode
• merge side tag

What would this workflow look like? Something like this?

• request side tag
• set _with_bootstrap macro to 1
• build everything that needs to be bootstrapped
• set _with_bootstrap macro to 0 (or remove it)
• build everything in non-bootstrap mode
• merge side tag

Yes, that is the idea

I think what macros to allow in general is a complicated topic. But we can deal with a much narrower issue more quickly:

PROPOSAL: Packagers can set %_with_bootstrap macro in sidetags.

If we go this way, this should be possibly extracted into separate ticket.

IOW this tickets could be used to find and agreement that setting macros in side-tag is acceptable and probably which governing body is going to decide. If this is clear, then we could proceed with specific macros should they be evaluated separately.

(And in general, for other macros, I think we

Part of the question was who is "we" :) But I assume that this means you'd like to keep this power in FeSCo hands.

should approve them one-by-one. At least for now, I don't see a good reason to allow arbitrary macros. This could quickly get messy.)

(And in general, for other macros, I think we should approve them one-by-one. At least for now, I don't see a good reason to allow arbitrary macros. This could quickly get messy.)

Just to clarify, this also was the sentiment in the rel-eng ticket and therefore Koji devels were so kind to implemented the whitelist.

But of course it is still an option to give a blanket approval :innocent:

"we" == FESCo. This is a FESCo ticket after all ;)

If we go this way, this should be possibly extracted into separate ticket.

I think we shouldn't split things up, since that'd split the discussion. I'm sure we can discuss both the narrower and wider topic in the same ticket successfully.

But of course it is still an option to give a blanket approval 😇

I'd be fine with that too, if there's some justification why that'd be useful.

But of course it is still an option to give a blanket approval 😇

I'd be fine with that too, if there's some justification why that'd be useful.

Less bureaucracy.

Also packagers already have the power to influence the macros enabled in buildroot via dropping them into a file such as %{_rpmconfigdir}/macros.d/macros.foo without any approval. This is just a bit more convenient way of doing the same.

Just FTR this was the initial ML thread which got use here:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BKUPTP6GVZ2CUUJJK22I5ZAW6XGLRYUB/

I am absolutely +1 to the %_with_bootstrap proposal.

I hesitate about a blanket approval: yes, you can simulate it by having a package drop a file into place, but this has the beneficial side-effect of recording that this happened in the git history. In the case of %_with_bootstrap, the altered Release field provides that same record.

PROPOSAL: FESCo acknowledges that modifying the macro configuration on side-tags can be useful, but can also be problematic. As such, we require that any such configuration be approved by FESCo. FESCo will maintain a list of such approvals in the packaging guidelines.

+1 also to the second proposal.

+1, but nitpick: "FESCo will maintain a list of such approvals in the packaging guidelines" should likely be "FESCo will maintain a list of such approvals in the FESCo policy pages"
Unless we want to delegate this to the packaging committee?

The specific location doesn't really change the intent, so insert the appropriate place as needed :)

The %_with_bootstrap macro is the only macro that allows (under certain circumstances) building the same commit twice. Any other macro we allow changing this way (except maybe %dist, which I suppose we won't allow changing) will require a bump/empty commit anyway. When doing that, it might be more explicit to set the macro in the spec.

+1 to allow %_with_bootstrap
+1 to maintain the list of approvals @ FESCo
-1 for blanket approval

Same here:

+1 to allow %_with_bootstrap
+1 to maintain the list of approvals @ FESCo
-1 for blanket approval

Though I'm wondering how setting bootstrap to on, then to off, will affect rpmautospec? I assume that both packages will only differ by the "bootstrap" string in the Release tag, and have the same changelog contents, so that should be fine, but it might be good to test this, since a lot of packages are now using rpmautospec.

If somebody is interested, @mizdebsk experimented with the %_with_bootstrap macro in staging Koji:

$ koji edit-sidetag --rpm-macro _with_bootstrap=1 f39-build-side-$n

https://koji.stg.fedoraproject.org/koji/buildinfo?buildID=2191109

$ koji edit-sidetag --remove-rpm-macro _with_bootstrap f39-build-side-$n

https://koji.stg.fedoraproject.org/koji/buildinfo?buildID=2191110

Maybe I could ask mock / koji devels to record the predefined macros somewhere for auditing purposes 🤔

Maybe I could ask mock / koji devels to record the predefined macros somewhere for auditing purposes 🤔

https://pagure.io/koji/issue/3875

It was pointed out to me that the @sgallagh proposal is ambiguous. Let me reword it (including @kevin's nitpick):

PROPOSAL: FESCo acknowledges that modifying the macro configuration on side-tags can be useful, but can also be problematic. As such, we require that any such macro be approved by FESCo. FESCo will maintain a list of approved macros in the FESCo policy pages.

IOW s/any such configuration/any such macro/ and s/such approvals/approved macros/, where the former might be explained that each use of e.g. the %_with_boostrap macro would need specific approval.

There is already history on this in the koji db:

✗ stg-koji list-history --tag f39-build-side-66874        
Mon Jul 24 07:42:45 2023 new build target: f39-build-side-66874 by mizdebsk
Mon Jul 24 07:42:45 2023 new tag: f39-build-side-66874 by mizdebsk
Mon Jul 24 07:42:45 2023 added tag option sidetag for tag f39-build-side-66874 by mizdebsk
Mon Jul 24 07:42:45 2023 added tag option sidetag_user for tag f39-build-side-66874 by mizdebsk
Mon Jul 24 07:42:45 2023 added tag option sidetag_user_id for tag f39-build-side-66874 by mizdebsk
Mon Jul 24 07:42:45 2023 inheritance line f39-build-side-66874->f39-build added by mizdebsk
Mon Jul 24 07:44:22 2023 added tag option rpm.macro._with_bootstrap for tag f39-build-side-66874 by mizdebsk
Mon Jul 24 08:48:13 2023 plexus-cipher-2.0-4.fc39~bootstrap tagged into f39-build-side-66874 by mizdebsk
Mon Jul 24 08:52:36 2023 tag option rpm.macro._with_bootstrap removed for f39-build-side-66874 by mizdebsk
Tue Jul 25 05:58:29 2023 plexus-cipher-2.0-4.fc39 tagged into f39-build-side-66874 by mizdebsk
Tue Jul 25 06:02:47 2023 plexus-cipher-2.0-4.fc39~bootstrap untagged from f39-build-side-66874 by mizdebsk
Tue Jul 25 06:02:47 2023 build target deleted: f39-build-side-66874 by mizdebsk
Tue Jul 25 06:02:47 2023 tag deleted: f39-build-side-66874 by mizdebsk
Tue Jul 25 06:02:47 2023 tag option sidetag removed for f39-build-side-66874 by mizdebsk
Tue Jul 25 06:02:47 2023 tag option sidetag_user removed for f39-build-side-66874 by mizdebsk
Tue Jul 25 06:02:47 2023 tag option sidetag_user_id removed for f39-build-side-66874 by mizdebsk
Tue Jul 25 06:02:47 2023 inheritance line f39-build-side-66874->f39-build removed by mizdebsk
Tue Jul 25 06:02:47 2023 plexus-cipher-2.0-4.fc39 untagged from f39-build-side-66874 by mizdebsk

Thats not in the UI anywhere I don't think though, but I am not sure where it could be. I guess on the tag's page.

+1 to the proposal

I'm a bit confused what is being voted on in different comments. Can we officially vote on the latest version (from https://pagure.io/fesco/issue/3046#comment-866557) please?

PROPOSAL: FESCo acknowledges that modifying the macro configuration on side-tags can be useful, but can also be problematic. As such, we require that any such macro be approved by FESCo. FESCo will maintain a list of approved macros in the FESCo policy pages.

I am +1 for this proposal, and I'd also be +1 to adding _with_bootstrap as the first (and only) macro that's allowed at the beginning.

Same. +1 and +1

Same. +1 and +1.

After more than two weeks:
APPROVED (+3, 0, 0):
- FESCo acknowledges that modifying the macro configuration on side-tags can be useful, but can also be problematic. As such, we require that any such macro be approved by FESCo. FESCo will maintain a list of approved macros in the FESCo policy pages.
- _with_bootstrap is approved as the first macro.

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OBMMZPBV363JBINPKVN3X642GCEQ3GMC/

Thx for approving this.

Re: documentation. Is this the right section?

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#_side_tags

I probably can put something together.

And I think that we could also include the list of approved macros in the documentation, right? Assuming that FESCo does not want to track it in some separate place

Oh, I wrote this before seeing your comment:
https://pagure.io/fesco/fesco-docs/pull-request/76
But that's fine: we want a short page with policy, and in the PUG, an explanation how to set the macros, etc. So once PUG is updated, we can add a link in the FESCo docs.

Oh, I wrote this before seeing your comment:
https://pagure.io/fesco/fesco-docs/pull-request/76

:thumbsup:

But that's fine: we want a short page with policy, and in the PUG, an explanation how to set the macros, etc. So once PUG is updated, we can add a link in the FESCo docs.

I have opened PR here:

https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/133

Any feedback is welcome

The docs on our side were merged. The pr for package maintainer docs hasn't been merged yet, but we don't need to wait for it here.