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. -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
