Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote:
> The new “rolling” suite
> -----------------------
> This would be a pseudo-suite, like experimental. Except that while
> experimental is built on top of unstable and filled manually by
> maintainers, rolling would be built on top of testing and filled
> semi-automatically. A rolling system would have typically 2 APT lines:
> one for testing and one for rolling.
This is an excellente proposal which technically can be implemented this
way:
- having a new britney instance, which is chained to the result of the
"testing" britney.
- it is fed with a new hint file composed of "forced" migrations
(those are versionned), feeding the result of the testing britney
with sid.
- result is a new release only made of testing or unstable packages.
If you find the people wanting to make up the rolling team, I think it's
a few hours work to setup (and overhead on the ftp servers would just be
minimal: a new suite and associated Packages files, nothing more).
Doing it this way:
- leverages the same tools as what we have now (britney, dak);
- only uses packages either in unstable or testing, which makes
rolling a glorified Pin-file hence people using rolling don't
diverge from the stable release work and are actually *worthwile*
bug reporters and gives more coverage on testing *excellent*.
- benefits from the release work: e.g. if a package is removed from
testing, since rolling is recreated from that, it inherits that
(nothing prevents the rolling team to force it back for whichever
reason).
- allows to take snapshots of rolling on a semi-regular basis (with
associated d-i releases). E.g. every 3 months or so. Those would be
alphas before the freeze, and betas during the freeze.
I like it a lot, I'm even finding it useful: it looks like it resolves
the rolling issues for people (wrt having something like a 'Usable'
testing), but doesn't really forks testing, only glorified pinning
managed at the project level instead of on each other's machines. But it
doesn't make those users worthless to the release team, quite the
contrary.
It could even turn-up to become a useful release tool.
I just love that proposal. At least something technical that makes
sense, thanks Joss.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Reply to: