On Wed, 22 Sep 2010 08:47:31 +0200 Mike Hommey <mh@glandium.org> 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. Splitting the user base / testing base isn't necessarily a good idea. In other words, it might work for heavily utilised packages but it would cause a lot of complexity in bug triage. How is the maintainer meant to test the version in unstable if he's running the frozen version or vice-versa? > 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. With something like iceweasel, is there frankly any point in building experimental versions on architectures which can barely handle the stable releases? How many users are there using iceweasel not on x86/x86-64? > This could be more work, but I understand that for people who want to > do it, the testing freeze time is frustrating. New versions break stuff - there has to be a way of stabilising bleeding-edge code and that should not be in a quiet backwater with no users. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpleji3w_LZ8.pgp
Description: PGP signature