NoOp wrote:
On 08/01/2011 12:47 PM, Bill Davidsen wrote:
Jens Hatlak wrote:
hawker wrote:
That said 2.2 has had the most regression bugs,
lost features and new bugs of any version I have seen since before 1.0.
I hope this new "rapid" release is not causing SM quality to suffer and
this is just a bad build that we will get past. What is the feeling of
the development team on this build or is this just the build where the
issues have finally gotten to areas that affect me?
Yes, SM 2.2 contained more issues than usual. We tried to fix some
issues 2.1 had but others popped up, especially in MailNews and the
address book (some things were not fixed entirely, and changes
Thunderbird developers made to shared MailNews code were not fixed on
our end fast enough).
2.2 was the first release after we switched to the rapid release
process, and in this case we had even fewer time than the usual 6-18
weeks that the process dictates because 2.1 had already been delayed.
Also there are some problems that appear due to the all-volunteer nature
of the project. There are only very few developers in the first place,
reviews (which are mandatory for any code change) take quite long. In
former times (before 2.2) we had many months time to fix things and
release "when it's ready". Now we're pretty much date-driven. This
requires paying more attention to regressions by everyone involved.
There is a lesson to be learned there, and I think 2.3 will be better
overall [even though I personally would have voted to respin 2.3b1 so
that we don't release a beta with major issues that are already known to
be fixed for 2.3].
Personally I'm not a huge fan of the rapid, date-driven release process
either but we have little choice: Security fixes (which usually affect
Gecko or other code shared with Firefox) are only fixed on the latest
stable Mozilla platform version so we cannot skip one without exposing
our users to security risks. This is (very) unfortunate but nothing we
can influence, so there is no point in complaining about it. We have to
make the best out of it.
So does the API of Gecko change with every release? I would think you would be
calling for services and fixes would be in the service. Does it really change so
much that you can't link against the current code?
I like the Linux model, where stability fixes are provided against recent
releases, so people don't have to constantly upgrade. I would think that was a
problem for Mozilla and corporate users as well, and a reason to provide bug fix
only support for 90 days or six months, or something reasonable. No corporation
I have supported would update softweare every six weeks, other than to apply
patches.
Might be an interesting read:
<http://news.cnet.com/8301-30685_3-20074590-264/rapid-release-firefox-meets-corporate-backlash/>
Frankly, I think Mozilla has lost touch, expecting people to do an upgrade every
six weeks. And forced silent upgrades? I may be wrong, that may be "default"
rather than "forced," you can protect yourself if you remember to do so. Still,
no support after six weeks seems to be ceding the serious browser market to others.
An interesting read indeed.
--
Bill Davidsen <[email protected]>
We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination. -me, 2010
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
