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

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
  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

- 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.

Raphaël Hertzog ◈ Debian Developer

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

Reply to: