[cut-team] Ideas for the rolling release

Raphael Hertzog hertzog at debian.org
Mon Aug 16 14:18:46 UTC 2010


Hi,

On Mon, 16 Aug 2010, Reinhard Tartler wrote:
> This depends on the implementation. If we want to snapshot testing
> (which I am actually in favor for), then packages would first need to
> migrate to testing anyway. But that would also mean no transition
> fast-tracking.

Snapshots and a rolling distribution are not in opposition. One is needed
for the installation media anyway.

> Again, I fear that will seduce maintainers to upload crack-of-the-day
> packages to unstable, disturbing the 'regular' unstable migration
> espc. during freezes. This again is very likely to make the work of the
> release team more difficult.

It's certainly a risk, that's why I later suggested that rolling and
testing should ideally be the same during the development and diverge only
on freeze. If we go to the end of the logic, once testing is branched off
rolling, it only gets direct bugfixes: either cherry-picked from unstable
when possible or directly uploaded to the frozen branch much like we
handle stable updates.

>   - the 'cut-rolling' suite contains (semi- ?) automated backports from
>     *experimental* (not testing). Direct uploads to 'cut-rolling' are not
>     permitted. This should encourage people that care for 'cuts' to care
>     for testing at the same time, even if that only means to not disturb
>     the 'regular' testing migration. QA for 'cut-rolling' is therefore
>     ensured on two levels:

I think using experimental here is only a bad way to avoid maintainer
uploading stuff to sid that is targetted to rolling without consideration of
testing.

I don't find this a good design.

> I don't think that toolchain packages (like gcc-defaults, binutils,
> debhelper, cdbs, etc.) are well suited for the purpose of 'cut-rolling'.

It depends. The idea of rolling is also to alway allow pushing the latest
stable version out to users even during a freeze.

For packages like dpkg it means we can continue pushing out new features
during the freeze and really maintain two branches in parallel.

But this requires that testing stops relying on unstable during the
freeze to get fixes.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)



More information about the cut-team mailing list