use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting)

Axel Thimm Axel.Thimm at ATrpms.net
Mon Jun 4 18:56:27 UTC 2007


On Mon, Jun 04, 2007 at 12:45:07PM -0500, Tom spot Callaway wrote:
> On Mon, 2007-06-04 at 19:45 +0200, Michael Schwendt wrote:
> > On Mon, 04 Jun 2007 11:14:51 -0500, Tom "spot" Callaway wrote:
> > 
> > > I'm not against a pre-final-freeze, scheduled mass rebuild of devel. I
> > > think that would solve the "omg, my disttags look old" fears and catch
> > > some minor issues.
> > >
> > > Is it redundant for some packages? Yep.
> > > Does it hurt those packages to be rebuilt automagically once during the
> > > cycle? No.
> > > Does it help us catch broken packages before final freeze? Yes.
> > 
> > Does it bear the risk of producing new breakage? Yes.

You need to take a firm standpoint, Michael, either the packages are
not broken and a rebuild won't break them, or they are and a rebuild
to uncover this is needed. :)

> > (for lots of packages, features are dropped silently when
> > configure tests fail)
> 
> These are things that need to be fixed. We can either find out that
> they're broken or just hide from them. By having this on a set
> schedule, then asking maintainers (and QA) to test the mass-rebuild
> resulting packages, we'll find these things and fix them.

+1000^1000

> > An automatic mass-rebuild does not involve the maintainers at all.
> 
> No, but really broken packages help identify AWOL maintainers.
> Admittedly, the lucky AWOL maintainers whose packages keep building as
> is forever and ever will not be caught by this.
> 
> > It would be different if the maintainers were asked to update/rebuild
> > their packages prior to a deadline. Only that would request a sign of
> > life.
> 
> I thought about this, but it wouldn't ensure proper ordering between
> packages. Packager A rebuilds after Package B is done, but changes to
> Package A affect Package B's build.

The mass rebuilds won't place that in order either, but: If the people
against mass rebuilds argue that ordering is an issue, e.g. building A
against the old B will fail or give a broken result, then ordering is
the least to worry about.

The ordering is not an issue if the rebuild happens twice and the
first set of packages are thrown away. Kind of bootstrapo convergence.

Rebuild early, rebuild often ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070604/1ffe559a/attachment.sig>


More information about the Fedora-maintainers mailing list