[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What should we do with iceweasel/xulrunner/libmozjs?

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

Reply to: