On Wed, Sep 22, 2010 at 08:26:22AM +0100, Neil Williams wrote:
> On Wed, 22 Sep 2010 08:47:31 +0200
> Mike Hommey <firstname.lastname@example.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?
How is the maintainer meant to test the version in stable if he's
running the unstable version of vice-versa?
Anyways, yes, it might work for heavily utilised packages, but on the
other hand, they are exactly the kind of packages where it would make
> > 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?
There frankly is one: that of catching bugs early. For example, I
already know iceweasel 4.0 betas are broken on several of our
architectures. If I hadn't tried to build it once, I wouldn't have
realized until I uploaded 4.0 final, at which point it's even harder to
get fixes upstream, which means yet more patches applied to our package.
For instance, being able to work on 4.0 since its early days helped
getting the number of patches from 100+ on 3.5 and 3.6 down to around 50.
> How many users are there using iceweasel not on x86/x86-64?
Do you realize the iceweasel package is not about iceweasel alone? Check
the number of build-rdeps and rdeps on libmozjs, and xulrunner.
And who knows what future netbooks may bring more users for mips or arm,