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

Re: Mozilla plans for the squeeze cycle



On Fri, Aug 21, 2009 at 03:39:55PM +0200, Alexander Sack wrote:
> On Sun, Aug 16, 2009 at 02:41:21PM +0200, Marc Brockschmidt wrote:
> > Heya,
> > 
> > As announced on dda [RT1], we want to get an impression when releasing
> > Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
> > 2009, and some developers have noted that their planned changes wouldn't be
> > possible in this time frame. So, to find out when releasing would work for
> > most people, it would be great if you could answer the following questions:
> > 
> 
> > * Which major upstream releases of Mozilla/Xulrunner-based software are
> >   expected in the next two years? Which of those are material for Debian
> >   stable, which might be a bit flaky?
> 
> firefox 3.6 is currently scheduled for december 2009; i think it would
> be worthwhile to get that in before freeze even if its not yet final
> at that point; this would help to get a bit longer upstream security
> support and would make debian more modern. Also it will probably get
> to final during freeze.
> 
> Mozilla does not have any 2 years plans that one could rely on. Last I
> know is the general goal to target a ~9 month cycle, but with usual
> approach to release when ready (so 3.5 took 12 month).

And security support is dropped 6 months after that for the previous
release. I.e. Firefox 3.0 security support will be dropped in 4 months.

Firefox is also not the only mozilla product we have, and only
considering Firefox may be biaised.

Thunderbird 3.0 might be expected somewhen soonish in the next few
months, as well as Seamonkey 2.0. They will both be based on Gecko
1.9.1, which is the version of Gecko that Firefox 3.5 uses.

Getting all these in sync means we share the same codebase in all
Mozilla products, which, despite upstream support being dropped earlier
may substantially help the security team.

Firefox 3.6, on the other hand, relies on Gecko 1.9.2.

I, for one, don't want to maintain 2 gecko codebases in the same
distribution much longer. But people are free to join the mozilla team
and help out.

> > * How much time do you usually need from a new upstream release to a
> >   stable Debian package in unstable?
> >
> > * How many "big" transitions will the upcoming changes cause? When should those
> >   happen? Can we do something to make them easier?

Every new gecko, which we mainly have in xulrunner nowadays, needs some
work, though I do hope 3.6 will require less work than 3.5 has and will.

ATM, 3.5 is definitely not release-ready, and a lot of work remains to
be done:
- Build and test rdeps against newer version (applications such as
  epiphany[1], and plugins)
- Patch liboggplay, liboggz, libvorbis, libtheora, etc. with the
  necessary patches, and make sure it doesn't break other packages.
- Build xulrunner against these patched libraries instead of the bundled
  oned as currently is the case.

Once we're done with this, the same will have to done again for 3.6. As
the whole depends on more than myself alone, it's hard to give an
evaluation on how long these transition will take. I'm not even able to
say how long it will take me to get 3.5 itself in shape.

Cheers,

Mike

1. Note that epiphany may be totally dropping gecko support in the near
future (and I hear yelp and devhelp should, too), but that still leaves
us with at least galeon and kazehakase.


Reply to: