So I need to update golang-github-acme-lego, and it happens to have new dependencies :
Basically I have 49 new Go packages to get reviewed.
Go packages are following a standard templates, so you don’t need to do the whole fedora-review thingie.
What I usually check for templated Rust and Go package is :
- License ok
- Latest version packaged
- Builds in mock
- No rpmlint errors
- Conforms to Go Packaging Guidelines
The entire set of packages is built in this COPR :
You can add it in your mock file :
name=Copr repo for golang5 owned by eclipseo
so you don’t have to bother with dependencies to check if it builds.
Do you have a tool that you use to generate the spec files for all these packages?
I wonder if we should change the policy to waive the review requirement for packages that are generated using this tool. I feel like having manual reviews of these packages creates a lot of unnecessary work.
The things Robert mentioned still need to be checked for tool-generated specs. We still need to check the content is acceptable, the license is OK, and all of that stuff. A spec generator does not and cannot check that for us.
Could someone self-review these things?
I think it kind of defeats the purpose.
Sure experienced packagers from the SIG could probably do it, but another pair of eyes is always a good thing. And the licensing can be tricky sometimes.
For newcomers, I don’t think saying you can self review Go/Rust packages is a good thing.
Perhaps “batch reviews” would be a more appropriate means of streamlining the review process? Templated Go and Rust packages often show up in big bundles, like @eclipseo’s 49 here, because they’re all pulled in as new dependencies for some other package that’s the “real” final target. So perhaps there’s a way those here-because-they’re-needed-more-than-wanted dependency packages could be bundled up into a single Review Request ticket and done all together, even though they’re not actually related (beyond all being dependencies of the same also-unrelated package)?
Perhaps even a slightly-modified form of perfunctory, streamlined “Templated Packages Review Request”, where it focuses exclusively on the things mentioned in the OP, and cuts out all the other chaff that normally has to be ignored while performing reviews of such packages.
I approved the following:
Self-review sets up an inherent conflict of interest. When the submitter’s goal is to get their package added to Fedora in a short time frame, it is inevitable that shortcuts will be taken; even with experienced packagers this happens. Effective review needs an independent 3rd party whose primary motivation is analysing the packaging guidelines, not adding the package.
Thank you very much! Let me know if I can review something for you!
Yeah, self-review isn’t even really review. I mean, we’re all supposed to look over our packages and ensure they meet the guidelines before submitting them anyway, so self-review is really already part of the process. But a second, independent pair of eyes is the critical check that keeps us from getting lazy.
How do I generate the rpmlint output? I know I’ve done it before but can’t find the command.
Edit: Looks like all of these packages have reviews but I’d still like to find out the command line for rpmlint.
I just run fedora-review on the package and it does it log the rpmlint output in the results.
Otherwise you run the rpmlint command on all the artifacts (*.rpm, *. spec).
I have comment each one. Ping me when you have updated the files.