[cut-team] lightweight rolling alternative

[Raphael Hertzog]

Hi,

On Thu, 09 Sep 2010, Joey Hess wrote:
> But here's another way to deal with the problem that seems easier to
> implement and explain. What if instead of a separate full-fledged
> rolling suite, we had a backport-like repository, tied to a specific cut
> snapshot, that contained packages that were misssing from testing at the
> time the snapshot was made. It could also hold newer versions of
> packages, though we'd want some policy about that. If we had that now,
> we could either rescue chromium-browser 5 from the morgue and put it in
> there, or we could backport chromium-browser 6 from unstable to there.

This would suffer from the same problems that you identified
in http://lists.debian.org/20100908151433.GA1648@gnu.kitenet.net (except
for the pinning that would not be required), no?

For this specific problem of missing packages in testing due to
unsupportability of a given upstream version for a period of 2 years
or more, I would like to sugggest that we're addressing the problem at the
wrong level with additional suites. What about accepting them in stable
but letting users know of the additional constraints ("might change with
new upstream version during the release's lifetime") and letting them
configure APT to accept or not packages marked as "volatile" or
"security-with-new-upstream"? (this APT feature doesn't exist yet)

I wanted to elaborate on this idea and make a basic proposal on -devel
but if I can get early feedback here, maybe it can avoid me spending too
much time on something that most people find crazy (or on the contrary
improve the proposal).

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

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