Fedora Extras packaging beta software into production repos, why?

[Michael Schwendt]

On Mon, 30 Oct 2006 15:29:21 +0100, Denis Leroy wrote:

> Michael Schwendt wrote:
> > That puts FE into a situation where we don't offer a working set of
> > packages as long as the remaining packages are still under review, but
> > which increases the risk that it breaks something our users have either
> > built themselves or downloaded from 3rd party repos. At fedora.us we've
> > always tried to publish complete dependency chains.
> 
> Agreed, that seems common sense to me. Though of course we have to live 
> with the limits of the review process. For example Michael, you're 
> reviewing gideon which I submitted (as a side note, i just got renamed 
> 'crow', i'll have updates soon), but has dependencies on 2 other 
> packages from the same author which I had to submit for review and build 
>   separately (and update as well to match the version of gideon under 
> review). Is there an alternative to a serial dependency chain like this 
> ? Bulk, or group reviews ? If some 3rd party repo had gideon available, 
> it would have been difficult to go through the review process for all 3 
> without causing a conflict at some point.

There is a simple solution: --> All or nothing. <--

[...]

Don't build pieces of a package-set just because they are approved
already. Keep all dependencies in FE-ACCEPT state until the other packages
in FE-REVIEW are approved, too.

Consider FE-ACCEPT a freeze. Don't apply further updates, not even version
upgrades, as that creates a moving target. You can do all that in CVS or
in a private working-copy until the whole show is ready.

When your reviewer approves a package from your set of packages,
apparently it's good enough as a build requirement for the pending
reviews, isn't it? At least the reviewer should have performed a
test-build of the complete package-set to verify that everything works
together.

Among the things that slow down reviews are:

* Reviewers, who demand minor version upgrades without pointing out any
  issues.

* Packagers, who apply many changes to a package which have not been asked
  for.