What should we do with iceweasel/xulrunner/libmozjs?
Benjamin Drung
bdrung at debian.org
Fri Feb 18 09:29:27 UTC 2011
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/attachments/20110218/9628cd78/attachment.pgp>
More information about the pkg-mozilla-maintainers
mailing list