Am Freitag, den 18.02.2011, 10:12 +0100 schrieb Mike Hommey: > Hi, > > Now that squeeze is released, it's time to start pushing new things to > unstable. I've been asked several times already how things would be > evolving in the near future, to which I answered it would quite stay the > way it is now until upstream releases 4.0, at which point I'd upload 4.0 > to unstable. But that might change. And I'm hereby requesting feedback > on what fellow developers (especially maintainers of the various reverse > dependencies) think about them. > > Here are some of the available options: > > - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push > 4.0 to unstable when it's out. > Pros: More exposure for the 3.6 and 4.0 packages. > Cons: More work for reverse dependencies, which would be made to build > and work with 3.6 and then again with 4.0 in a few weeks. > Last time I checked (which was 3 months ago), 4.0 doesn't work > on s390, sparc and ia64, which would make problems. > > - Keep things the way they are (3.5 in unstable, 3.6 in experimental, > 4.0 betas on mozilla.debian.net), and upload 4.0 to unstable once it's > released. > Pros: we don't need to make sure everything in unstable builds and > works properly with 3.6 before doing the work again with 4.0 in a > month or so. > Cons: Broken architectures with 4.0. > > - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental > when it's released. > Pros: We don't break anything in testing/unstable, and we don't have > to deal immediately with the broken architectures. > Cons: We lose version 3.6, which has several advantages over 3.5, and > keep 3.5, which is already very outdated. > > - Keep everything in place, prepare rdeps to build and work with 4.0, > and push 4.0 to unstable when everything is ready. > Pros: We don't break anything in testing/unstable, and when 4.0 lands > on unstable, nothing breaks either. > Cons: Past experience shows that it takes a lot of time to fix rdeps. > My gut feeling is that breaking things in unstable would create an > incentive to fix, which doesn't exist when the package is in > experimental or worse, outside the archive. > > - Suggest your own if you have better ideas (really, I mean it). > > As I mentioned above, my initial idea was to go with the second option, > breaking most rdeps in the process, but then I remembered that 4.0 > doesn't work on all our architectures, and I'm hesitating, now. > > So, fellow developers, what do you think? I favor a combination of idea one and two, which is: Keep 3.5 in unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Then we have one big break and a tested 4.0 in unstable. -- Benjamin Drung Debian & Ubuntu Developer
Attachment:
signature.asc
Description: This is a digitally signed message part