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

[davi at gnu.org]

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.


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.


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