RPM submission procedure

[Enrico Scholz]

steve at 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