[cut-team] Daily wheezy snapshot installation media now available

[Michael Gilbert]

On Fri, 18 Feb 2011 15:11:35 +0000 davi at gnu.org wrote:

> Michael Gilbert wrote:
> > Adnan Hodzic <adnan at foolcontrol.org>
> 
> > > My general idea for determining media was after "big" things have been
> > > rolled into testing, for example new kernel, udev, or even new
> > > Chromium version for that matter. After that kind of things, "cut"
> > > would be made.
> > 
> > I was thinking more of a mostly schedule-based process (with of
> > course flexibility for when things are really broken). That way users
> > can plan around a upgrading to the new CUT say once a month on about the
> > same day every month.
> 
> Not all packets in a new Debian-testing-snapshot have the needed quality to 
> enter in a new CUT release.

We haven't really defined a quality metric for CUT yet

> The approach should be:
> 
>   instead of cherry picking packages from the 'new' testing,
>   ban to enter CUT the ones with release critical bugs.
>   So only what is at good state enter in the next CUT.
> 
> 
> After testing that CUT a little, to check there are not package dependence 
> problems and so on, release it.

That's how the current stable release process is done.

> > > I'm not sure if you tried to say the same thing, but I would make it
> > > available for general public after ~<= month "cut" has been made, and
> > > has been tested.
> > > 
> > > Testing time of the "cut" should be measure by how many "cuts" do you
> > > want until the "final" release.
> > 
> > OK, here's my plan, and I'm very open to thoughts on improvements.  The
> > first CUT release candidate will be the first image of every month.
> > There will be a call for testing to -devel, and if no significant
> > showstoppers are reported to this list by the 5th day of the month,
> > then that will be the official release for the month.
> > 
> > If there is a showstopper, the previous images will be bisected and
> > tested until the one before that problem was present. That will then be
> > release candidate 2.  There will be a call for another 5 days of
> > testing, and if no show stoppers are found, then that will be the
> > official release for the month.
> > 
> > This can be done multiple times, and if we get all the way back to the
> > previous month's image, then we'll just skip the release for that
> > month since it's just too buggy.
> 
> That testing process could be good or not. I am not an expert about that 
> subject.
> 
> I just note that filtering the packages, "by release critical bugs" and so on, 
> is a basic test which allows get for CUT all the rest of the new stuff which 
> is in Debian testing.

RC bugs are a metric for the stable release.  Things move too fast in
testing for that to be the sole metric for CUT as well.  Also if that
were the case, CUT wouldn't be any different from a stable release, so
what would be the point?

Anyway, since CUT is a testing release, we don't need to impose any
stringent requirements.  I would say that many things can remain broken
in a CUT as long as default installation options continue to work and
the system is bootable/working directly after the install.

Best wishes,
Mike