SM 2.2 state WAS: Sidebar Search change in 2.2

[Jens Hatlak]

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.


Greetings,

Jens

--
Jens Hatlak 
SeaMonkey Trunk Tracker 
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.2 state WAS: Sidebar Search change in 2.2

[Philip TAYLOR (Webmaster, Ret'd)]

Jens Hatlak wrote:


2.2 was the first release after we switched to the rapid release process,


Jens, can you say more about this switch to the rapid release process, for
the benefit of those of us who are outside the "inner circle" and are
therefore probably unaware of what this rapid release process is, and why
it was instigated (and at whose behest ?).

Philip Taylor
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.2 state WAS: Sidebar Search change in 2.2

[Jens Hatlak]

Philip TAYLOR (Webmaster, Ret'd) wrote:

Jens Hatlak wrote:

2.2 was the first release after we switched to the rapid release process,


Jens, can you say more about this switch to the rapid release process, for
the benefit of those of us who are outside the "inner circle" and are
therefore probably unaware of what this rapid release process is, and why
it was instigated (and at whose behest ?).


Basically it means that a new major stable version is released every six 
weeks, and security updates will only be fixed for that new version; the 
previous versions are discontinued instantly. Since the Mozilla platform 
(the rendering engine Gecko etc.) is bound to the Firefox release 
schedule, that decision didn't leave us with much of a choice. We had to 
follow suit(e).


This was brought up by the Firefox guys, who wanted to have more and 
quicker releases to bring new features (especially support for new web 
technologies) to the 200+ million people that use Firefox. Previously 
new major stable versions only appeared after many months, often years. 
Their decision made some waves; especially corporate users are now 
mostly left in the cold. Efforts were announced to work on those issues 
but it's unclear what the outcome will be.


HTH

Jens

--
Jens Hatlak 
SeaMonkey Trunk Tracker 
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.2 state WAS: Sidebar Search change in 2.2

[Philip TAYLOR (Webmaster, Ret'd)]

Jens Hatlak wrote:


Basically it means that a new major stable version is released every six weeks, 
and security updates will only be fixed for that new version; the previous 
versions are discontinued instantly. Since the Mozilla platform (the rendering 
engine Gecko etc.) is bound to the Firefox release schedule, that decision 
didn't leave us with much of a choice. We had to follow suit(e).

This was brought up by the Firefox guys, who wanted to have more and quicker 
releases to bring new features (especially support for new web technologies) to 
the 200+ million people that use Firefox. Previously new major stable versions 
only appeared after many months, often years. Their decision made some waves; 
especially corporate users are now mostly left in the cold. Efforts were 
announced to work on those issues but it's unclear what the outcome will be.


Very many thanks, Jens : much appreciated.  My personal feeling is
that this does not bode well, for Firefox, for Seamonkey and for
anything Gecko-based.  I just hope I am proved wrong.

Philip Taylor
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.2 state WAS: Sidebar Search change in 2.2

[Bill Davidsen]

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.


--
Bill Davidsen 
  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
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.2 state WAS: Sidebar Search change in 2.2

[NoOp]

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:



___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.2 state WAS: Sidebar Search change in 2.2

[Bill Davidsen]

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:



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 
  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
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey