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

What should we do with iceweasel/xulrunner/libmozjs?


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
  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?


Reply to: