Jeff Spaleta wrote:
the checksumming automation is going to become increasingly
problematic as more maintainers look to pull things from upstream code
management repositories instead of 'released' tarballs.
Then we can leave that part out. There's a lot we can and should automate.
* Is the BR tag one of the 3 approved versions?
* Is the License tag valid? (this does not mean someone shouldn't
verify the license matches the source, we could maybe automate that too
but it's probably harder)
* Does the %install section start with a clean BR?
* Make sure packages aren't using PreReq
* Make sure it builds in mock
* Check the spec's encoding
* Make sure that use of %{buildroot} vs $RPM_BUILD_ROOT is consistent
* Make sure that there are no cases of Requires(pre,post)
* Make sure %files doesn't reference %{_datadir}/locale/*
* Check for an appropriate %clean section
etc.
Automating this stuff will let reviewers focus on a smaller set of
issues. Which means less chance of forgetting something, and more time
for them to review more packages.
But another thing we can do is go through the Review Guidelines[1] and
remove all the duplicate items. For example, it says:
- MUST: The package must meet the Packaging Guidelines[2].
The Packaging Guidelines say:
* You should go through the Packaging/NamingGuidelines to ensure that
your package is named appropriately.
* You should review the Packaging/LicensingGuidelines to ensure that
your package is licensed appropriately.
Guess what the next two items in the Review Guidelines are?
If you keep reading, you'll see a lot more duplicate items (%{buildroot}
vs $RPM_BUILD_ROOT, %clean section, etc). Having duplicated info during
the review process slows down the reviewer. We should make sure there
is one concise page that has the review process. Flipping back and
forth is error prone, and just adds a layer of complexity. You're
already flipping between a page and a spec file. Flipping around to
other pages is just pain.
[1] http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
[2] http://fedoraproject.org/wiki/Packaging/Guidelines
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
