I've been struggling to keep the Rust stack reasonably up-to-date over the past few months, and the fact that many new Rust packages are not "correctly" set up by their packagers, is not helping. Despite my best efforts to post reminders after approved package reviews, and to post ~monthly reminder emails to the "devel" and "rust" lists, the situation is not really improving.
The kinds of issues I'm faced with include:
1) Rust packages are not associated with the "rust-sig" group, so queries for bugs with "rust-sig" as assignee or in CC are incomplete. This makes it harder for me to keep an overview of TODO items, especially release-monitoring / anitya, FTBFS, and FTI bugs.
2) Rust packages are not set up with release-monitoring.org. This results in missing release notifications, and applications getting built against potentially buggy or insecure versions of their dependencies. This is exacerbated by the fact that Rust binaries are statically linked, so even if dependencies are updated at some point, applications will already have been built against older versions. I try to ensure this is not the case by updating the Rust stack basically "from the bottom up", prioritizing libraries. This is in contrast to most other Rust packagers in Fedora, which prioritize their own packages for Rust applications, and only touch library packages if their application updates make it necessary.
3) Tracking for new Rust packages is not enabled on koschei. Koschei is a really important tool for me, because it lets me see regressions that are caused by Rust compiler and / or library updates very quickly. Not having all Rust libraries and applications enabled on koschei gives me an incomplete picture and will potentially let some breakage slip under the radar unrecognised.
I briefly talked about this problem with @churchyard , and it looks like the following policy would make sense for Rust packages:
The Rust SIG group (@rust-sig) MUST be granted "commit" or "admin" co-maintainer status on all packages for Rust crates. Packages that only contain Rust code, but which are not Rust crates themselves (i.e. they are not published on - and packaged from - crates.io) are exempt from this rule (firefox, thunderbird, and 389-ds-base are examples of this).
We could not come up with any reason to exempt packages from this rule (except the exemption for "complex" not-only-Rust packages, which is already included), but there could always be exempted packages, for which we could just maintain a list. So the policy would basically cover all packages where the source name matches rust-*, minus those on the aforementioned (probably empty) list.
rust-*
As adding @rust-sig with commit ACL to a package is the only thing that I cannot do myself without cooperation of the packager, this would make my work much easier. Adding packages to koschei and setting up release-monitoring can by done by everyone without needing special permissions, so I don't think this needs to be covered here.
@rust-sig
commit
A similar policy would probably also make sense for @go-sig, as @fale has already reached out to me that he's facing similar problems in the Go stack.
@go-sig
What do you think?
This all seems perfectly reasonable to me.
Is there a reason we don’t enable Koschei by default on new packages and branches?
Hi,
As @decathorpe mentioned, go-sig is in the same situation, and I agree that this would be the reasonable (in my opinion) way to solve this.
Enabling Koschei by default seems reasonable to me, but I might be missing some key information on this.
The Rust SIG group (@rust-sig) MUST be granted "commit" or "admin" co-maintainer status on all packages for Rust crates.
Sounds good. Can we make this automatic, e.g. by tweaking the tool that releng uses to create dist-git repos, or through some tool that periodically adjusts settings in dist-git?
+1 to the proposal
Can we make this automatic...
We can, but I'd rather we don't make that a condition for approval. AFAIK @decathorpe has scripts that can mass add the group, but lacks the (1) ACLs to do that (2) rule that would allow him to do it. Once we have the rule set, I will gladly run the script once in a while as I do have the ACLs.
+1 then
If we are voting on the proposed policy, then I am +1. Somebody should probably propose a corresponding policy for Go.
I have a script, but it's very simple ... you give it a list of packages and it adds @rust-sig group to them. I sent this out with my regular emails so people who had a lot of packages to process could at least do so automatically, but it could of course be re-used to implement this policy, by querying for SELECT package where package.name matches 'rust-*' and '@rust-sig' not in package.acls, if you pardon my SQL, and then run the script for these packages.
SELECT package where package.name matches 'rust-*' and '@rust-sig' not in package.acls
https://gist.github.com/decathorpe/9d128982cb00e2d345d9e397372538ec
FWIW, I'm also +1 to my own proposed policy. :)
Somebody should probably propose a corresponding policy for Go.
I thought of this ticket to be generic, and FESCo could decide which SIGs / package sets to apply this rule to, but sure, let's decide on Rust first, and if the Go SIG wants this policy to apply to Go packages as well, that can be handled in another ticket.
We are close to automating processing branch/new package requests, so IMHO we should add this to automation, but it shouldn't be that hard. Just a config where we can list a regex and a additional commit group, but thats details. :)
I'm also in favor personally of just enabling koschei and release-monitoring for all new packages (and/or possibly enabling it in mass for everything except specific packages that opt out). But I think that should be discussed on the devel list seperately from this proposal.
I'm also in favor personally of just enabling koschei and release-monitoring for all new packages (and/or possibly enabling it in mass for everything except specific packages that opt out).
I think the following are true:
But I think that should be discussed on the devel list seperately from this proposal.
I agree with this proposal. @decathorpe has been sending the spring cleaning emails for months, and it feels like an exercise in futility at this point, so I support escalating this problem. @fale has also sent a couple of these emails for the go-sig, and I've personally reminded some maintainers, but there's still a fair amount of packages that we don't have permissions on.
As for go, we'd want this to cover all go packages (@decathorpe's rust proposal is a bit more limited in scope). This issue has been especially problematic in the context of the recent go CVE rebuilds, which include all go packages with binaries, whether or not they provide a corresponding -devel package. (Unfortunately, there has been a recent barage of go CVEs). There are really only two provenpackagers (@eclipseo and as of today, me) who are able to handle rebuilding the packages that the SIG doesn't have access to, and we're not always around. There are other go-sig members (e.g. the actual golang package maintainers) who should be able to handle this without needing extra permissions.
-devel
golang
Not having permissions also makes it hard to keep the go stack in working order, and can prevent us from fixing bugs in and updating other packages when maintainers of their dependencies don't respond to PRs.
This seems APPROVED (+4,0,-0)
Metadata Update from @churchyard: - Issue tagged with: pending announcement
Should we add this policy to the FESCo docs?
Metadata Update from @churchyard: - Issue tagged with: document it
Well, it needs to be mentioned somewhere. I think it makes sense to mention it in https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ despite it not actually being a "packaging" guideline. If this would not be comfortable to FPC, we could spell it in FESCo docs and add a note to https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ that links to it, but that seems as overkill.
I'd rather have it documented in a "neutral" place, assuming that the Go SIG will ask for the same or a similar policy to apply to golang-* packages / the go-sig group, as well.
I agree with @decathorpe. Even if the Go SIG wasn't interested in a similar policy (we are), I think FESCO policies should be documented in FESCO's docs, even if they're also mentioned in the Packaging Guidelines or other places.
Announced:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6VAM5N54Z4AJQ7XVYFSZZFC6QTG26P7H/
Should I file a PR for the FESCo docs?
Metadata Update from @decathorpe: - Issue untagged with: pending announcement
Yes please.
(@decathorpe thanks for the pointer). The newly created r-maint-sig group could greatly benefit from this policy too.
PR with initial draft: https://pagure.io/fesco/fesco-docs/pull-request/66
It only covers the Rust SIG, because this is what was approved by FESCo.
If other SIGs want to be covered by this new policy as well, they can look at what's already there for the Rust SIG (explicit criteria for which packages are covered, and what actions to apply to them), and propose similar changes.
Thanks for this work. Let's wait for PR66 to be merged, and then we could propose extensions for other SIGs.
PR66 has been merged.
Metadata Update from @zbyszek: - Issue untagged with: document it - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
I will gladly run the script once in a while as I do have the ACLs.
Does that offer still stand? If so, I can submit a PR to add a Python script that does what the new policy states.
Sure.
I've created https://pagure.io/fesco/fesco-docs/pull-request/68 for Go-SIG. I think it's aligned with what was voted here. If not, I'll open a specific request for it. Thanks a lot :-)
In the same way, I've created https://pagure.io/fesco/fesco-docs/pull-request/69 for the R SIG.
I've prepared a script to execute the new policy, but I am unsure where to put it.
Originally I wanted to add a scripts/ folder in the fesco project, but it apparently has disabled Pull Requests, so I can't submit it here.
scripts/
Adding it to the scripts in the "releng" project seems like the wrong place, since it's not a release engineering thing. That git repo also requires a Signed-off-by for all git commits, but I'm not even sure what I'm supposed to sign-off-on ...
Signed-off-by
(Just noting that I am also planning to add all Haskell packages to a Haskell group too, soon.)
That git repo also requires a Signed-off-by for all git commits, but I'm not even sure what I'm supposed to sign-off-on ...
You can put this to the commit message:
Signed-off-by: There's nothing to sign off here, let me alone.
And I think it works. But yes, I agree that the requirement is... weird. However, releng is probably the best repo we have for this kind of stuff and I do have the right to merge PRs there.
Done: https://pagure.io/releng/pull-request/10982
I've proposed https://pagure.io/fesco/fesco-docs/pull-request/72 as a similar policy for the Flatpak SIG. I think it is aligned with what was voted here, but the ticket is several months old now - should I file a new one for FESCo to vote on adding one more SIG?
Login to comment on this ticket.