Do we want extras/testing/{4, 5} repos (was Re: Packaging review guidelines clarification)

[Ralf Corsepius]

On Sun, 2006-02-19 at 07:57 +0100, Thorsten Leemhuis wrote:
> Am Sonntag, den 19.02.2006, 05:47 +0100 schrieb Ralf Corsepius:
> > On Sat, 2006-02-18 at 18:54 -0500, Dan Williams wrote:
> > > On Sat, 2006-02-18 at 14:28 -0500, Jeff Spaleta wrote:
> > > > On 2/18/06, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> > > > > I know, it doesn't work to well with update-testing in core -- but it's
> > > > > IMHO better then no testing at all.
> > > > 
> > > > If this policy goes in I'd want an established  loophole that allows
> > > > hot fix updates to fix brokenness that made it through the "testing"
> > > > timeout without comment and not just security updates.
> > > 
> > > So this is appearing to get more and more complicated.  I'm not sure
> > > adding more process onto this is the best thing; more process is (a)
> > > confusing and (b) a damper on participation.
> > I agree with your concerns and do not see much benefits.
> > 
> > Why can't we have a maintainer must give explicit clearance to release a
> > successfully built package policy instead of automatically releasing a
> > package?
> > 
> > That would mean, a successfully built package would end up in a
> > publically accessible repo (or directory), but maintainers would have to
> > explicitly give clearance for a package to be pushed to the official FE
> > repos.
> 
> We did this in fedora.us -- it worked, but didn't worked too well IMHO.
You seem to forget about fedora.us's underdeveloped infrastructure.

> Some packages stayed in the "pending" repo for weeks or even months
> because nobody checked them. This is probably even more process then a
> testing-repo and adds more bureaucracy for the maintainer; so it
> probably (a) confusing and (b) a damper on participation.
> 
> A defined testing repo with a automatic move to the public trees could
> have the benefit that (a) multiple people can check the package easily
> (just enable extras-testing, they get the packages with the next yum
> update), (b) a package might be checked on multiple archs this way and
> (c) it will be pushed even if the maintainer does nothing.
If don't see much sense in this and don't see any need for it.

What I sense as missing is:

* Maintainers currently have no means to withdraw a miss-built package,
even in obvious cases (E.g. package completed building successfully, but
a configure check for an optional feature had failed, because another
package had changed).

* Maintainers have no means to provide "packages for testing" to
individuals who reported a bug on their particular situation.
Maintainers have to resort to shipping such testing packages from their
private sites, and ... thereby don't have any means to provide binaries
for archs they don't have access too.

* Maintainers have no means to test building packages on archs they
don't have access to.

* In most cases, "testing" packages will not be connected to other
packages, but will be try-n-error packages addressing issues against
packages in FE(released). Setting up a testing _repo_ therefore is
highly useless, because it would contain functionally broken packages.


If we had a  "pending" directory (no repodata), maintainers could
initiate builds, check the built packages [1], direct individuals to
manually downloading this package and to try a particular change they
have applied for this built. 

Ralf

[1] A problem I am frequently facing is: Buildsystem reported a
successful built, but I didn't have any chance to look into the ppc-rpm
before it has been released.