Summary from yesterdays (mini) FESCo meeting

[Michael Schwendt]

On 29 Dec 2006 11:24:19 -0600, Jason L Tibbitts III wrote:

> MS> Any more formalism and bureaucracy will drive away reviewers. I
> MS> think we've agreed on that long ago. I'm surprised this topic has
> MS> returned.
> 
> I as well, and I objected to this when it came up.
> 
> I prefer a much simpler rule: please just tell us what you checked.

It is not feasible. Certainly not for me. It is inefficient. Having to
document each and every minor detail I perceive while reviewing a package
would require using a completely different work-flow. There are countless
things that can raise the reviewer's attention in random order while
displaying a spec, while perusing patches, while skimming over a
test-build log, while listing the binary rpm contents in verbose mode,
while looking into the rpms with Midnight Commander and displaying files
of interest, while visiting upstream's web site and reading about stable
versus development branches, while test-driving the executables (an
increasingly popular check is to enter the Help menu and see whether the
documentation or online help system works). Not only would it need a huge
check-list (perhaps a tree rather than a list, and a single page in a text
editor would not be enough) that grows with every package which requires
different things to review. A reviewer would also need to document many
things that don't apply. It would not result in better initial packages.

Rather than requiring reviewers to be pedantic, better encourage packagers
to be more verbose in their spec file comments. Or require them to add
comments in some cases: Explicit "Requires"? Let the packager add a
comment as why they are necessary and why the automatic deps are
insufficient.  Snapshot instead of stable release? Let the packager add an
explanation.  Disabled features, non-default configuration options, or
probably overlooked feature options? Require the packager to add a
comment.

> As the review is permanently kept as evidence, reviewers should not
> leave things open to question.  If you looked at something and found
> it OK, please indicate that instead of asking others to assume that
> you checked something and found it not worth commenting on.

Why? Silent observers are irrelevant. Only if an observer finds something
arguable and points it out, it gets interesting. Either the packaging
guidelines cover it or not. If all people involved think the package is
okay, then fine. Mission accomplished. What are the goals of doing package
reviews? Do you want to aim at perfection? Simply assume that it is in the
reviewer's best interest to not approve a package that has flaws.
Certainly not a package with serious flaws. At the pace some packagers
pipe out updates to their packages every few days, there is enough room to
fix subtle packaging bugs after the one-time review+approval. To catch the
big fish is the point of doing reviews.