[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Review queue/FESCo after the merge

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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]