[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

unstable-proposed-updates (was: For those who care about their packages in Debian)

* Ian Jackson [2010-08-25 13:42 +0100]:
> Perhaps the right answer is to simply ask people to upload
> non-release-related stuff to experimental rather than unstable.  That
> way one can do the itch-scratching right away; moving packages from
> experimental to unstable later is easy ...
> Even better would be an option to write something in your .dsc which
> would cause automatic transfer of your package into unstable when
> testing is unfrozen.  Distro target of "experimental-unstable"
> perhaps.  That way we could automate the "flood of new packages and
> distro is totally broken" effect :-).

I thought about something like this a while ago and would have called it
'unstable-proposed-updates'.  Currently experimental is used for both,
experimental packages and packages the should go to unstable in future,
a new suite to split this would it make possible to differentiate
between really experimental and other packages.

Possible advantages of having unstable-proposed-updates:

 * During a freeze, people could continue to upload new versions without
   the need to use t-p-u if they need to get fixes to testing. For
   example, this would have prevented a broken libpam-mount from
   entering lenny during freeze.  A (semi?) automatic migration to
   unstable after the freeze (maybe in batches) would save the
   maintainers some work.  Maintainers could still use experimental
   instead for their packages if they don't like this automatism.

 * CUT could get updates through u-p-u instead of unstable during freeze
   (currently unstable often misses new upstream versions in that time
   and alternatively letting packages migrate from experimental wouldn't
   be the best idea because some of the packages could really be

 * Maybe it could also be helpful to coordinate transitions, the release
   team would then just move packages from u-p-u to unstable when they
   think it is the right time.  Additionally they could set triggers
   that would automatically move specific packages to u-p-u instead of
   unstable when they are uploaded.  The release team knows best if this
   would help them ;)

* Russ Allbery [2010-08-25 01:13 -0700]:
> Yves-Alexis Perez <corsac@debian.org> writes:
> > Would it be possible (at one point) to “fix” it and stop using
> > unstable as t-p-u and experimental as unstable when freeze is in
> > action?
> We could try to get lots of people who normally use unstable to
> instead test testing plus t-p-u, but I'm not sure they'd be willing to
> do so.  I for example don't want to switch my unstable systems to
> testing plus t-p-u for a variety of reasons.

I think this point is important, people will not switch to the
distribution we think they should use in specific release phases. This
is also the reason why I don't think things like adding another
distribution between stable and testing or testing and unstable would
have the desired effect.  Instead we should ensure that what we have
(testing and unstable) contains what we want most of our non-stable
users to use and test.

If there would be a good reason to add t-p-o or u-p-o to their
sources.list, then I think some users would do so, but I expect this
still to be the minority.  One such reason to add u-p-o could be that
they want to use newer software than what is currently available in


Reply to: