Paul B. Gallagher wrote:
MCBastos wrote:
But, the thing is, with limited resources available, supporting
those old releases means that the new release does not receive as
much work as it needs. With Seamonkey tied to the every-six-weeks
Mozilla release schedule, delaying release is not an option. So
supporting the old releases is no longer viable.
As our parents used to ask, "If everyone else jumped off a cliff, would
you do it, too?" Just because the FF people decided to rush things and
churn out a series of half-baked products for the sake of keeping up
with the Joneses, why should we ape them?
(and /please/ don't ask me to keep my metaphors straight)
Without going into the details of why your diatribe is wrong and
bothersome...
We're not acting like Lemmings, we're acting like realists. The fact is
that Firefox (along with Core Gecko, which we depend on) is moving to a
"rapid release cycle". We weighed our options here, which include things
like the following (not all inclusive):
* Follow the Rapid Release train wholesale, release whenever Firefox
Releases.
* Maintain a 6-9 month stability release ourselves, for every version we
release; and follow the Firefox cycle for every major release the whole
time.
* Maintain a 12 week support cycle for each and every release, skipping
every other Firefox/Gecko release.
The problems with those other solutions, is that not only is it
confusion for others (Like l10n, which diverging too much would make
releasing matching localized builds much harder). It also means that we
would be VERY hard pressed to diagnose, fix, and maintain any security
fixes that are uncovered.
Most security issues in Gecko Code are fixed by those Core Gecko
Developers, not simply because "we don't have time" to touch that code,
but because we don't _know_ the internals of that code as well as them.
So a bug that they could theoretically fix in a day, would take us a
week or more. And security bugs tend to involve a much deeper knowledge
about how all those moving parts fit together.
To preempt the question of "why not just fix in a branch what they just
fixed in trunk" ... it's not always that easy. There could have been a
code refactor in trunk code meaning that fixing it on our branch would
be MUCH harder since we have to work from scratch. Also the fix they may
employ in trunk could involve web compat changes, (such as say, they
discover a bustage in cross site requests, where the fix is to update
our implementation to a completely new version of the specification --
our commitment on stable releases is NOT to break those web compat issues)
Lastly if we just "do nothing" on those branches, we leave you, our
users, open for web-based attacks, that can manifest viruses, password
stealing, facebook proliferation (without your consent) among other
serious issues.
In the end the "Follow the Firefox plan of a rapid release" is the only
viable solution. The only solution that actually plans to keep you, our
users, supported and happy. If Firefox comes up with a solution to the
enterprise that does not involve manpower in hand-holding the
enterprise, we'll follow suit (we don't have man power to handhold all
our users)
We don't necessarily have to like the plan on their side, but it is
either abandon SeaMonkey, or follow suit in the end. We decided to
follow suit.
It was not an easy choice, and one that if we knew *in advance* of
Firefox 4's EOL right away, we would have released a SeaMonkey on Gecko
1.9.2. Where before the Gecko Rapid Release Plan was finalized, it was
presumed (rightly) that Gecko 2.0 (Firefox 4.0) would have the same
level of support that 1.9.1 and 1.9.2 had previously, and that is what
we had intended to release SeaMonkey 2.1 on; When that story changed it
was a bit of a surprise to us, but we adjusted the best way we could
given our options.
****IF you are ANYONE else complains about us being lemmings, I'll just
point them at this post, and proceed to ignore you. No more useless
diatribe about us and our choice here. THANKS ****
--
~Justin Wood (Callek)
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey
