Justin Wood (Callek) wrote:
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...
Fine, and I won't go into details of why a question is not a diatribe.
At any rate, the answer that follows is very helpful and informative,
unlike the other responses, and it does answer my question. Moreover, it
confirms the premise that the SeaMonkey team has adopted a rapid-release
schedule largely /because/ the Firefox team did so. And it makes clear
that the decision was well-thought out, which was the other half of my
question.
You must've expected when you made the decision, or at least you know
now, that lots of users are unhappy with versions 2.1 and 2.2 and have
been complaining about bugs, broken and lost features, etc. This isn't
my diatribe, it's just the content of the newsgroup, and it comes with
the territory of releasing every six weeks. If I keep my mouth shut,
you'll still get plenty of complaints from others, so I can't help you
there.
I should probably include for the peanut gallery my standard disclaimer
that I'm a long-term SeaMonkey, Mozilla, and Netscape user (going back
to NS 4.x) who would like nothing better than for SM to be a great
program with a large following. And I don't see the rapid-release
schedule as contributing to those ends. YMMV.
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 [or] 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 ****
--
War doesn't determine who's right, just who's left.
--
Paul B. Gallagher
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey
