Good idea. Reorganized for larger issues at the top and implementation
notes at the bottom.
Christopher Aillon wrote:
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.
Absolutely a goal to shoot for.
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?
Actually, at some point the FPC made an effort to merge the
ReviewGuidelines and the PackagingGuidelines so that the two were
different views on the same thing. One is a checklist of problems to
check. The other gives reasoning and notes exceptions to those rules.
So the real issues are:
1) this has to be made clear on ReviewGuidelines
2) the two lists have to be checked to make sure they both are complete
at this point
3) the two lists have to be kept in sync.
[From a previous email]
> This web app will build the SRPM in koji, can check the md5sum of the
> tarball vs upstream
>
At one time we wanted to make sure that packages went through review
before being built in the buildsystem. This was to protect the
buildsystem from malicious packages trying to compromise it. However, I
think koji's ability to scratch build an arbitrary SRPM does an end-run
around this requirement anyway....
= Implementation Details =
When checking the md5sums automatically, we have to make sure that the
human understands they still need to verify that tarballs are being
downloaded from a canonical upstream location. And the human will have
to verify that things match upstream when the upstream source is a
source control tree as well.
> * 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)
Right. So we'll need human interaction to supplement the automation here.
> * Check the spec's encoding
This also needs human supplementing. We can check that the spec file is
ASCii but how are we to tell that the non-ASCii characters in there are
UTF-8 without a human looking at the context?
-Toshio
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
