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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110428135228.gb7...@rivendell.home.ouaza.com