Re: Bits from the Release Team - Kicking off Wheezy
On Thu, 28 Apr 2011, Mehdi Dogguy wrote:
> | before | during | release
> | freeze | freeze | day+1
> | dev period | |
> ———————————————————————————————————————————————————————————
> | sid | sid | sid
> before | testing | testing (frozen) | testing==stable
> | stable | stable | stable
> ———————————————————————————————————————————————————————————
> | sid | sid | sid
> after | testing | testing | testing
> | stable | frozen | frozen (new stable now)
> | | stable | oldstable
> ———————————————————————————————————————————————————————————
>
> Is this what you have in mind?
Yes (except you missed oldstable in the cell "before / release day+1").
> How's rolling different from testing? (except that testing freezes from
> time to time… yes, I know, that's the main point of the proposal, but
> still, I want to know if there are other changes).
It's not different.
There are other possible changes but I want to discuss them separately
because even without those changes, the testing without freeze is a
worthwhile goal in itself.
Still, since you seem to insist, here are ideas I'd like to investigate:
- reduce the set of architectures required for migration to testing to
i386/amd64/armel and have buildd of other architectures prioritize
missing builds in testing over missing builds in unstable
(freeze should be enough time even for slow arches to catch up and FTBFS
on already release architectures is still RC)
- be less strict and keep old binaries (and thus 2 versions of the same
source package) in testing. This applies in particular for libraries
going through SONAME changes and which can happily coexist during a
transition.
Re-enable the strict requirement a few months before freeze, and get rid
of the old binaries/versions during freeze (eventually dropping any
package which has not been updated if required).
- 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)
But please let's keep this for later (or at least start a new thread if
you want to comment on those ideas). They are ideas, I'm not attached to
any of them, I have not studied which one would have the most impact, etc.
Do not confuse those ideas with the current discussion to introduce rolling
as a non-freezing testing.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: