steve@silug.org (Steven Pritchard) writes:
Personally, I think style issues should be reserved for *after* any package has made it into testing, at least.
No, when a package is in a public repository it is too late. People will begin to use this repository as default one since it has lots of cool packages. Since packages are already published, bugreports will have a low priority for the packagers and bugs stay forever (rawhide is a good example).
The current fedora.us way were only positively reviewed packages are published is the right one.
My only other complaint, and it really is more of a suggestion, is that it would be *really* nice if the easy things (like "does this package build") were automated.
Agreed, but there is infrastructure missing for fedora.us to provide such a service. I am not sure if it would be worth to spent time into the implementation of a package-database + improved QA methods, since Red Hat never told its requirements. So it may be, that they are saying "nice work, but in the last months we developed our own methods/tools which are obsoleting yours", or "your stuff is voilating our ideas and can not be used for Fedora Extras".
It would be *really* nice if the automatically-built packages were put into a repository (accompanied by USE AT YOUR OWN RISK warnings) that reviewers could download and test from. At that point it becomes almost zero effort for interested people (like me) to install a package on a test box and let it run for a while.
Current fedora.us procedure implements the reverse way: at first, QA people are doing functionality and buildtests (inclusive spec-file auditing), a testpackage will be built and packager has to verify it.
Perhaps, the first stage should be shortened to buildtests and spec-file auditing only. Then the verification phase should be replaced by a second cycle which is doing QA tests only.
But I am not sure if this would shorten the QA process... ;)
Enrico