On September 22, 2010 01:35:14 am Mehdi Dogguy wrote: > On 09/22/2010 08:47 AM, Mike Hommey wrote: > > On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote: > >>> Then unstable/testing would roll further as usual > >> > >> How does a major, disruptive, transition get done? > > > > I think his proposal boils down to this: we *always* have unstable > > and testing to upload whatever we want and handle transitions when > > we like. Then, parallel to unstable/testing, there would be the > > pending/frozen suites to work on the release. Saying it a bit > > differently, we would *also* already be working on release+1 while > > release is being frozen. I kind of like the idea. > > > > To give an example with package names, I would already upload > > iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse > > dependencies until they are fixed to use xulrunner 1.9.2, while > > keeping updates for iceweasel 3.5 in pending/frozen. It would also > > allow me to push iceweasel 4.0 betas to experimental, where they > > would be better suited than their current location, where they are > > not even built on non x86/x86-64. > > It means that the Release Team will have to handle transitions in > unstable, migrations to testing, as well as the ongoing freeze in > "frozen". I don't think we have enough manpower for that. And, during > a freeze, we need each one to concentrate on fixing things (while > there is still experimental to test things). If we add a > play-forever-suite, we will loose some manpower without any doubt and > it will make releases harder to acheive, imho. > > Besides, how de we merge things after a release? unstable would be > something quite different from released frozen. Some bugfixes might > have been applied only for frozen or pending, some other package will > have new versions in unstable (and their rev-deps rebuilt)… I think > it could be a nightmare to manage, imho.
Unstable and Testing appear to quickly diverge from a new release's versions, becoming "something quite different from released", in a matter of days or few weeks. The only difference in this regard if a "frozen" existed would be that they could diverge sooner... wouldn't that be a headstart on the next Stable? What if packages only became "frozen" when the set of dependency relationships they are involved in is consistent (enough?) In this scenario there would be no (only minor?) transitions happening in Frozen, and consequently no (little?) need to merge dependency related bugfixes (the only "some" of consequence, afaict) into Unstable or Testing packages. Simply having that as a goal may encourage more or more prompt work on packages in Testing. I've heard that Testing cycles between good/installable and bad/un-installable--do those good times correspond to times when it would be possible to freeze a set of packages? i.e., is there already an indicator that can be used to trigger a mostly automatic action which over time would result in Frozen becoming a release candidate? anyways, here's a somewhat philosophical thought on the matter... Currently Debian can only "see" the past (Stable) and present (Unstable/Testing). Creating an always-consistent-"frozen" category of packages would let Debian "see" the past (Stable), present (Frozen), and future (Unstable/Testing). - Bruce -- 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/201009221117.16849.bms...@shaw.ca
