Re: A concrete proposal for rolling implementation
On 04/05/11 at 14:24 +0200, Josselin Mouette wrote:
> Hi,
>
> during the recent discussions about rolling, a proposal was made in a
> blog comment, and after giving it some quick thoughts, most people I’ve
> talked with seem to think it is a good idea, so it’s time for it to be
> discussed at large.
>
> It starts from the following fact: if you want a testing system that
> works correctly, you usually have to add APT lines for unstable, while
> pinning them to only install specific packages you need to unbreak
> what’s broken in unstable.
>
> The idea is to make this process automatic. Let me elaborate.
>
> 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.
>
> The rolling suite would only exist for a subset of architectures (we
> could start with powerpc, i386 and amd64), generated by picking up
> packages from unstable. Typically it would be generated from an override
> file that looks like:
> source-package version
> xserver-xorg-video-ati 1.2.3-4
> ...
> The rolling suite would try to have a package that has *at least* this
> version. If it is found in testing, the package is removed from rolling.
> If otherwise it is found in unstable, the package is picked from
> unstable.
>
> This way, when something is broken in testing and cannot be unbroken
> quickly, a maintainer who notices it could add (or make the people in
> charge add) the necessary packages to the override file. If, for a
> reason or another, an important bug fix or a security update doesn’t
> propagate to testing quickly enough, you can now just add it and the
> necessary dependencies to rolling, and people using it aren’t affected.
> Whenever the affected packages finally migrate to testing, the
> discrepancy between rolling and testing automatically disappears.
>
> The reason for the “at least” version rule is that new uploads to
> unstable are supposed to fix the situation in testing anyway. I don’t
> think we should keep in rolling packages that are no longer in unstable.
While I like the idea in general, I think that it should also be
possible to upload packages directly to rolling (through
rolling-proposed-updates). It will be useful in cases where neither the
package in testing, not the package in unstable, can be used to fix a
problem in rolling.
- Lucas
Reply to: