Pushing updates for Fedora 7

[Ralf Corsepius]

On Fri, 2007-06-01 at 13:42 +0200, Thorsten Leemhuis wrote:
> On 01.06.2007 13:20, Ralf Corsepius wrote:
> > On Fri, 2007-06-01 at 06:38 -0400, Luke Macken wrote:
> >> On Fri, Jun 01, 2007 at 09:07:36AM +0200, Hans de Goede wrote:
> >>>  Bastien Nocera wrote:
> >>>> On Thu, 2007-05-31 at 11:11 -0400, Jesse Keating wrote:
> >>>>> On Thursday 31 May 2007 10:58:31 Bastien Nocera wrote:
> >>>>>> Is it an enhancement, or a bugfix, or neither?
> >>>>> Enhancement (to the distribution)
> >>>> It would be easier if the update was a bit clever about new packages,
> >>>> and made them bypass updates-testing automatically.
> >>>  +1
> >> Just because it's a new package means it doesn't need to be tested? :)
> > No, because pushing packages into "testing" makes sense when chasing
> > specific bugs ("does this version fix kernel bug XYZ") or in case of
> > very complex packages (such as the kernel).
> 
> I'd say even in easy package there is always a chance something goes
> wrong, so in my opinion it IMHO would be best if all packages hit
> testing at least for a short timeframe.
This only makes sense if 
* there is somebody to test it
* there is something to test for

In many cases, their is neither. 

All "anonymous testers" without direct relation to a particular package
can test for "packaging" and "obvious" bugs (doesn't immediate
seg-fault).

Taking care about individual bugs, should be the job of the maintainer,
and be taken care during "hunting down a bug" (The bugzilla process).

Things get even more interesting if the Fedora maintainer is the
upstream. In such cases he is shipping the best available package, no
matter how broken and defective it actually might be.


Something like a "delay release" queue until maintainer OK's or
withdraws package or (short) timeout occurs make sense.

> > In most other cases, "testing" just means delaying packages and pushing
> > additional bureaucratic hurdles onto maintainers (yet more forms to fill
> > out).
> 
> Then let's try to get the hurdles down again that currently come each
> and everywhere . E.g. the workflow IMHO should be something like this:
> 
> - $ cvs commit -m "foo"
> - $ make tag
> - $ make build
> -- bodhi here afaics somehow needs to get some informations; e.g.
> --- from a file
> --- from the changelog
> --- via a parameter to make build
> --- simply by asking (similar how cvs will ask when you don't use "-m"
> - package goes to testing automatically
> - if nobody pushes a stop button in the next 4 (?) days something
> automatically should move the package to updates-proper

Well, something I've always missed in FE, is a "delay release" queue to
delay packages until a maintainer explicitly OK's ("make release")
or withdraws package or a (short) timeout occurs ("make withdraw").
Whether 4 days is a reasonable timeout, is arguable.

Ralf