Review queue/FESCo after the merge

[Toshio Kuratomi]

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