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

[Michael Schwendt]

On Mon, 4 Jun 2007 20:56:27 +0200, Axel Thimm wrote:

> 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. :)

Provided that it is uncovered. You didn't quote enough.

[Temporary] Side-effects in other [not closely related] packages can alter
the build results, too, for example.

The picture of when exactly the mass-rebuild would happen and how much the
the maintainers would be involved, is way too blurred. Talking about QA
and lots of automated tests, we're not there yet.

How do a devel cycle and a test period fit into this? If we test
previously built packages on the road to a final product that we want to
ship, why do we rebuild packages although nothing wrong has been found
with the binaries? Why take the risk of replacing working binaries (which
are assumed to work fine unless there are PRs) with theoretically we
should re-test from scratch? The dist tag alone is no sufficient reason to
mass-rebuild an entire distribution.