#2358 Drop the restriction on tagging for fedora-release
Closed: Accepted 2 years ago by zbyszek. Opened 2 years ago by zbyszek.

Currently a proven packager is not able to build fedora-release. The build succeeds but koji fails to tag the package:

  42640552 tagBuild (noarch): FAILED: ActionNotAllowed: policy violation (tag)

Proposal: drop special configuration for fedora-release (in koji or wherever exactly it is configured)

This is a simple package. We gain nothing by making the process around this package more complicated than necessary. Proven packagers can already write to the repo, and the inability to tag is just a trap.

[ In general, I think we need to proactively remove parts of bureaucratic process when they stop having a justification. There's just a few hundred Fedora contributors and when build elaborate processes that serve no purpose except their own existence we are wasting valuable contributor time and making the project worse off. A pointless restriction is not just pointless — it is actually hurting the project. ]

The discussion about simplifying the baroque process around fedora-release.rpm goes at least as far back as November 2017! The stuff proposed in [1] is now thankfully implemented and all points 1-4 therein are now done, and fedora-release releases happen fairly quickly. There has been definite progress, and this ticket would be the final small step closing this story.

[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CIKK4WEF5ACVWZ6EWBKNHSKKKCDTV27C/#CIKK4WEF5ACVWZ6EWBKNHSKKKCDTV27C


Chesterton's fence? Why is there the restriction in the first place? I have read the thread an must I agree that the "only releng can build this" restriction is bad. +1

If we want protection, I'd select "pull request access only" (cvsadmins, such as releng, can bypass that anyway).

pull request access only

Pull-request access makes sense when the package is non trivial but somewhat self-contained, and we get better testing by building the package in koji. I'd argue that in case of fedora-release, which is noarch, issues would fall in two categories: trivial bugs which can be diagnosed based on a local build, complicated bugs for which ones needs to do a compose and install other packages to see the effect. A PR is not needed to catch the first type, and will not catch the second type. While I think it is good to create PRs for fedora-release and that this should be the usual way of submitting modifications, especially for non-maintainers, -1 to making this required.

I was not proposing that officially. It was just an idea to prevent provenpakagers to go rogue.

So, @ausil might have more history but as I recall it:

Packages in the boot chain were setup so it requires a special permission to tag them. This was because we didn't want anyone to unintentionally break secure-boot and cause lots of problems for us due to that. fedora-release was added in the f19 timeframe where some changes were pushed from generic-release into fedora-release without discussion with releng and needed reverting.

I guess I'd be ok with fedora-release / fedora-repos being dropped from that channel now, but I'd say we should keep the others (kernel, shim, grub2, pesign).

On the other hand, I am not sure I see the rush most of the time, there are times when releng has several changes in process and it would make sense to just coordinate them and push them in one update instead of multiple ones.

Metadata Update from @zbyszek:
- Issue tagged with: meeting

2 years ago

I agree with Kevin. Maybe we could also add some [more?] sanity tests for this one to compensate for the change.

add some [more?] sanity tests for this one to compensate for the change

This argument has been raised before ;)
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HLB4J7ACVOBSXRK3O5YS67OAX7Q6BU6M/:

I am not opposed to it. I would however like to see a test suite built up.

It seems that the test suite wasn't really a prerequisite back then, since things moved forward without the test suite just fine. Saying "but we need a test suite" is a great stalling technique. So... if you think that we really need a test suite for fedora-release, please specify what this test suite is supposed to test and how.

Metadata Update from @zbyszek:
- Issue untagged with: meeting
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

2 years ago

We discussed this during today's FESCo meeting:
APPROVED: drop fedora-release and fedora-repos from the secure-boot channel (+7, 0, 0).

Login to comment on this ticket.

Metadata