Re: Bits from the Release Team - Kicking off Wheezy
On Thu, 28 Apr 2011, Joey Hess wrote:
> Another problem is that testing can be frozen in stages, which allows
> development from unstable on eg, leaf package to continue on filter into
> testing until relatively close to the release. Rolling could disrupt
> that, since uploads to unstable targeted at rolling would disallow
> easily getting the same uploads into testing (or frozen, or whatever you
> call it) once the two have diverged. So, much effort would need to be
> doubled.
Freezing base packages in rolling for 1/2 months would not be a big deal.
What matters is that end-user application keeps getting updated.
So the initial stage(s) of the freeze could be done in rolling,
we would then only create "frozen" at the start of the full freeze.
That seems a good compromise to me.
> some users can use is still available. I am unhappy during the current
> choke point of testing being frozen, but that choke point does serve as
> an incentive for the whole project to work in the same direction: toward
> actually getting a good stable release out.
I think that this incentive does not work. But it's difficul to get
numbers here except if we ask all maintainers and hope that they are
honest. Anyone willing to setup such a poll?
> We have a
> long stretch of time until the next freeze during which rolling won't
> be a benefit at all -- why start on it now? Why not work on improving
> testing's usability during this time, now that the intial post-release
> rush is (mostly; gnome excluded) over?
One does not forbid the other. But first I would like that the project
endorses testing/rolling as something whose usage is officially
supported (even if there are limitations on the level of support).
On Thu, 28 Apr 2011, Joey Hess wrote:
> Raphael Hertzog wrote:
> > - reduce the set of architectures required for migration to testing to
> >
> > - be less strict and keep old binaries (and thus 2 versions of the same
> >
> > - allow/encourage usage of t-p-u to rebuild unstable packages that are
> > ready to transition except for the fact that they are entangled in a
> > transition
> >
> > - have different level of RC bugs: there are RC bugs that are acceptable
> > in rolling that are not acceptable in stable, I'm thinking in particular
> > of FTBFS (and even more for FTBFS which affect non-common architectures)
>
> I think these are interesting ideas, but they don't seem to be specific
> to rolling; it seems they could be applied to testing just as well,
> and indeed mostly you've phrased them as applying to testing.
They are not specific to rolling.
But I don't plan to work on any of those if the project does not agree to
promote testing to something that can be advertised as usable by end-users
and as something that we strive to support on a best-effort basis.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: