Re: A concrete proposal for rolling implementation
Hi,
I came to the same conclusion than you after the discussion we had in
the comments of your article. I think it's the right approach. I still
have a few comments though.
On Wed, 04 May 2011, Josselin Mouette wrote:
> 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.
I think you meant "what's broken in testing" (i.e. you take a few selected
packages from unstable to fix bugs present in testing).
> 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.
It doesn't need to be a pseudo-suite. It's a collection of packages taken
in testing or unstable, it's not more complicated to make it a full suite.
And PR-wise, it's way better to avoid "testing" appearing in the
sources.list.
Also it means that the day where we have improved our processes in
unstable/testing so that rolling is no longer necessary, we can simply merge
testing and rolling in a single suite.
> The rolling suite would only exist for a subset of architectures (we
> could start with powerpc, i386 and amd64), generated by picking up
Why powerpc? If we really take more than i386/amd64 for rolling, there are
more users of armel than of powerpc.
> 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.
You still need some sort of britney to verify that the package is effectively
installable in rolling, and to verify you're not breaking installability
of other packages available in rolling.
But yes the basic principle is to stay as close to testing as possible, to
get as much as possible fixed via testing (in particular when it's
possible to fix via an updated version pushed through t-p-u) and for the
rest to cherry-pick some updates from unstable.
Once we diverged from testing, there's the question of what to do when the
package gets updated in unstable. By default the answer is "nothing"
unless the updated package fix a RC bug that is not present in testing
but that was introduced since then (and is now present in the rolling
version).
> Why I like it
> -------------
> First of all, this idea doesn’t affect *at all* the current release
> process. It just takes people willing to maintain the override file -
> and we could even choose to let any DD modify it. And it’s much faster
> to modify such a file than telling every user from testing that they
> have to upgrade to the unstable version.
I don't believe in the "let any DD modify it" but there should be a simple
way for DD to evaluate and submit such requests of integration into
rolling.
> And just as importantly, I think it should just work. There’s very
> little chance that people get completely hosed systems like it happens
> sometimes for unstable. There are all chances that something broken in
> testing can be fixed by pulling a handful of packages from unstable.
I agree with this. There might some corner-cases where we might require
direct uploads into rolling but if we stick to i386/amd64, it's easy
enough to do even without specific support on the buildd side.
> What to do during freezes
> -------------------------
I leave that aside for now. Your proposal covers the need to push newer
upstream versions to users but doesn't respond to the desire of developers
to continue development. But it's really another discussion so I prefer to
not discuss it in that thread.
> What do you think?
+1 from me. Thank you for the proposal!
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: