On Thu, Jun 24, 2010 at 05:28:41AM -0700, Bryan J. Smith wrote:
> Janne Blomqvist <[email protected]> wrote:
> > As a result of the new security policy of mozilla, that
> > relatively soon drops support for old releases,
> 
> I didn't note there was a new policy.

IIRC I read about it on some mozilla blog or such, but now I can't
find it; in any case, the ubuntu page I linked to and quoted from in
my previous post says essentially the same thing, so perhaps I didn't
just make it all up in my head.

What is new, OTOH, and that I forgot to mention in my previous
message, is that Mozilla is planning to introduce new features as well
as security fixes in stable branches (for example, the
out-of-process-plugins is a new feature introduced in 3.6.4). See

http://beltzner.ca/mike/2010/01/15/of-rumours-and-broken-telephones/

It'll be interesting to see whether RHEL chooses to upgrade to the
latest release in the stable branch (as has so far been done in the
3.0.x branch), or just backport the security fixes only on top of
3.6.4.

>  Red Hat continued to backport
> to Firefox 1.5.x for the longest time, and didn't make the move to
> 3.0.x until major updates on 4 and 5,

Yes, I remember that.

> Understand any time Firefox is rebased, there can be _major_ integration
> issues with enterprise desktops.  Firefox has a full object model, and
> can have mandatory and/or default preferences applies, including in LDAP
> stores (including in ADS as well, and with no more management difficult
> than MS IE -- long-time experience speaking here).  So that must be
> factored in.  If you're running thousands or even tens of thousands
> of enterprise desktops, that's an issue.  ;)

Well, over here we're in the O(100) range, and we have firefox
deployed pretty much out-of-the-box, so in our case I believe the
rebase won't be any problems, and our users will just be happy with
the new features and performance improvements. But yes, I can
certainly imagine the pain that others with fancier setups might
experience.

> Mozilla is still releasing 3.5.x revisions alongside 3.6.x revisions,
> at least through August.  I'm sure the planned end of 3.5.x had many
> reasons why the move was made to 3.6.4, along with many features that
> enterprises would like.  No sense in rebasing to a release that won't
> be supported for some time.  It's very likely 3.6.x will for some time
> with the focus on 4.x as the next, major release -- just like 1.5.x
> was.

Sure, if you're going to go through all the hassle of rebasing,
switching to the branch with the longest remaining time until EOL
would make sense, one would think.

> > at least Ubuntu has decided to track upstream more closely rather
> > than backporting fixes. See
> > https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel
> > """
> > In short or long term firefox is expected to move to a
> > changed branch policy; this most likely will involve even
> > shorter support for stable release branches. Numbers
> > discussed are: 4-6 weeks for minor security/stability
> > updates and 4-6 month for major version updates; at the same
> > time security/stability support for old branches will be
> > dropped.
> > In consequence, using our "old" way of backporting patches
> > for firefox becomes more and more unfeasible. The risks of
> > incurring distribution regressions is high, while the win is
> > debatable.
> > """
> 
> Ubuntu?  Or Ubuntu LTS?  Or both?

>From the link above it seems they are going to apply it to all
versions that are still supported, that is, both "normal" and LTS
releases. And in particular, the same firefox version on all releases.

> Don't know what one means by "at least."

I meant that based on the above link Ubuntu has decided to change the
usual "security fixes only" policy, but I don't know if any other
distro has also changed policy in a similar manner, which of course
doesn't preclude that from having been done; hence "at least".

-- 
Janne Blomqvist

_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list

Reply via email to