Re: [Mozilla Enterprise] Moving Firefox to a faster 4-week release cycle!

2019-09-23 Thread Jo Brown 
Security updates are point updates and are done EXACTLY the same time 
for ESR as security updates for regular Fx.  There is no lag and that 
supposed lag is NOT a reason to want to update faster.


As for how fast I want new features, I have finally left Fx ESR and 
regular Fx after having started with Phoenix, then Firebird betas, then 
Fx 1.0 so many years ago.  But I don't want new features except rarely 
and NO changes in the GUI.  I LOVE Basilisk.  It has everything I could 
possibly want in a great browser yet it is forked off of Fx 52 ESR. It 
is so outstanding that it doesn't need updates except rarely (of course 
it gets regular security updates) ...same with Fx 52 ESR which was the 
last great Fx.


On 9/22/2019 8:56 PM, Andrew C Aitchison wrote:


Paul,

On the whole I agree with you.

However, when my OS was on ESR I found that I often wanted the new features
"under the hood", particularly the security features, much more quickly
than ESR releases made them available.

I do agree that quantum and the switch of plugin api was an unfortunate
"under the hood" change.

On Sun, 22 Sep 2019, Paul Kosinski via Enterprise wrote:


I don't understand why a more rapid release cycle is good for *users*.
Bugs, especially security bugs, obviously should be fixed quickly. But
new features often tend to confuse users (many of whom can barely deal
with existing features).

I am pretty expert in using -- and developing -- software (having done
so since before Unix), but I prefer stability. I don't want changes in
behavior or GUI appearance of software I normally use to take time away
from whatever I'm working on, whether it's writing some C code, looking
up specs, or just watching some video.

The "rapid release" of new features is OK *only* if they do not change
the behavior, or GUI, of *existing* features. Even supposed stable ESR
has been seriously disrupted by Quantum. Quantum has been disaster in
this regard, as it has destroyed a tremendous number of important
Add-Ons, many of which cannot be recreated with the new API.

So I am skeptical of the desirability of a more rapid release cycle. It
might mainly be catering to users who view the browser as a game, rather
than a means to accomplish actual work.


On Fri, 20 Sep 2019 13:16:53 -0700
Ritu Kothari  wrote:


 We?re excited to announce

that we?re adjusting Firefox release cadence to increase our agility,
and to bring you new features more quickly. Starting Q1 2020, we plan
to ship a major Firefox release every 4 weeks.

Shorter release cycles provide greater flexibility to support product
planning and priority changes due to business or market requirements.
It allows us to be more agile and ship features faster while applying
the same rigor and due diligence needed to ship a high-quality and
stable release. *Major
updates to ESR* (Extended Support Release
 for the
enterprise) *will remain yearly, as they do now*. There will be a 3
months support overlap between new ESR and end-of-life of previous
ESR version. The next two major ESR releases will be ~June 2020 and
~June 2021. This change will be deployed gradually starting with
Fx71, achieving 4 week release cadence by Q1 2020. You can refer to
https://wiki.mozilla.org/Release_Management/Calendar for the latest
release dates and other  information.

As we slowly reduce our release cycle length, from 7 weeks down to 6,
5, 4 weeks, there will be close monitoring of aspects like release
scope change; developer productivity impact (tree closure, build
failures); beta code churn (uplifts, new regressions); overall
release stabilization and quality (stability, performance, carryover
regressions). Our main goal is to identify bottlenecks that prevent
us from being more agile in our release cadence. Appropriate
mitigations will be put in place should our metrics highlight an
unexpected trend.

If you have any questions or concerns, please email
release-m...@mozilla.com


Thanks,

Ritu Kothari

___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise 
or send an email to enterprise-requ...@mozilla.org with a subject of 
"unsubscribe"


___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise 
or send an email to enterprise-requ...@mozilla.org with a subject of 
"unsubscribe"


___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise 
or send an email to

Re: [Mozilla Enterprise] Moving Firefox to a faster 4-week release cycle!

2019-09-23 Thread Andrew C Aitchison 



Paul,

On the whole I agree with you.

However, when my OS was on ESR I found that I often wanted the new features
"under the hood", particularly the security features, much more quickly
than ESR releases made them available.

I do agree that quantum and the switch of plugin api was an unfortunate
"under the hood" change.

On Sun, 22 Sep 2019, Paul Kosinski via Enterprise wrote:


I don't understand why a more rapid release cycle is good for *users*.
Bugs, especially security bugs, obviously should be fixed quickly. But
new features often tend to confuse users (many of whom can barely deal
with existing features).

I am pretty expert in using -- and developing -- software (having done
so since before Unix), but I prefer stability. I don't want changes in
behavior or GUI appearance of software I normally use to take time away
from whatever I'm working on, whether it's writing some C code, looking
up specs, or just watching some video.

The "rapid release" of new features is OK *only* if they do not change
the behavior, or GUI, of *existing* features. Even supposed stable ESR
has been seriously disrupted by Quantum. Quantum has been disaster in
this regard, as it has destroyed a tremendous number of important
Add-Ons, many of which cannot be recreated with the new API.

So I am skeptical of the desirability of a more rapid release cycle. It
might mainly be catering to users who view the browser as a game, rather
than a means to accomplish actual work.


On Fri, 20 Sep 2019 13:16:53 -0700
Ritu Kothari  wrote:


 We?re excited to announce

that we?re adjusting Firefox release cadence to increase our agility,
and to bring you new features more quickly. Starting Q1 2020, we plan
to ship a major Firefox release every 4 weeks.

Shorter release cycles provide greater flexibility to support product
planning and priority changes due to business or market requirements.
It allows us to be more agile and ship features faster while applying
the same rigor and due diligence needed to ship a high-quality and
stable release. *Major
updates to ESR* (Extended Support Release
 for the
enterprise) *will remain yearly, as they do now*. There will be a 3
months support overlap between new ESR and end-of-life of previous
ESR version. The next two major ESR releases will be ~June 2020 and
~June 2021. This change will be deployed gradually starting with
Fx71, achieving 4 week release cadence by Q1 2020. You can refer to
https://wiki.mozilla.org/Release_Management/Calendar for the latest
release dates and other  information.

As we slowly reduce our release cycle length, from 7 weeks down to 6,
5, 4 weeks, there will be close monitoring of aspects like release
scope change; developer productivity impact (tree closure, build
failures); beta code churn (uplifts, new regressions); overall
release stabilization and quality (stability, performance, carryover
regressions). Our main goal is to identify bottlenecks that prevent
us from being more agile in our release cadence. Appropriate
mitigations will be put in place should our metrics highlight an
unexpected trend.

If you have any questions or concerns, please email
release-m...@mozilla.com


Thanks,

Ritu Kothari

___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise 
or send an email to enterprise-requ...@mozilla.org with a subject of 
"unsubscribe"


___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise 
or send an email to enterprise-requ...@mozilla.org with a subject of 
"unsubscribe"

Re: [Mozilla Enterprise] Moving Firefox to a faster 4-week release cycle!

2019-09-22 Thread Paul Kosinski via Enterprise 
I don't understand why a more rapid release cycle is good for *users*.
Bugs, especially security bugs, obviously should be fixed quickly. But
new features often tend to confuse users (many of whom can barely deal
with existing features).

I am pretty expert in using -- and developing -- software (having done
so since before Unix), but I prefer stability. I don't want changes in
behavior or GUI appearance of software I normally use to take time away
from whatever I'm working on, whether it's writing some C code, looking
up specs, or just watching some video.

The "rapid release" of new features is OK *only* if they do not change
the behavior, or GUI, of *existing* features. Even supposed stable ESR
has been seriously disrupted by Quantum. Quantum has been disaster in
this regard, as it has destroyed a tremendous number of important
Add-Ons, many of which cannot be recreated with the new API.

So I am skeptical of the desirability of a more rapid release cycle. It
might mainly be catering to users who view the browser as a game, rather
than a means to accomplish actual work.


On Fri, 20 Sep 2019 13:16:53 -0700
Ritu Kothari  wrote:

>  We’re excited to announce
> 
> that we’re adjusting Firefox release cadence to increase our agility,
> and to bring you new features more quickly. Starting Q1 2020, we plan
> to ship a major Firefox release every 4 weeks.
> 
> Shorter release cycles provide greater flexibility to support product
> planning and priority changes due to business or market requirements.
> It allows us to be more agile and ship features faster while applying
> the same rigor and due diligence needed to ship a high-quality and
> stable release. *Major
> updates to ESR* (Extended Support Release
>  for the
> enterprise) *will remain yearly, as they do now*. There will be a 3
> months support overlap between new ESR and end-of-life of previous
> ESR version. The next two major ESR releases will be ~June 2020 and
> ~June 2021. This change will be deployed gradually starting with
> Fx71, achieving 4 week release cadence by Q1 2020. You can refer to
> https://wiki.mozilla.org/Release_Management/Calendar for the latest
> release dates and other  information.
> 
> As we slowly reduce our release cycle length, from 7 weeks down to 6,
> 5, 4 weeks, there will be close monitoring of aspects like release
> scope change; developer productivity impact (tree closure, build
> failures); beta code churn (uplifts, new regressions); overall
> release stabilization and quality (stability, performance, carryover
> regressions). Our main goal is to identify bottlenecks that prevent
> us from being more agile in our release cadence. Appropriate
> mitigations will be put in place should our metrics highlight an
> unexpected trend.
> 
> If you have any questions or concerns, please email
> release-m...@mozilla.com
> 
> 
> Thanks,
> 
> Ritu Kothari
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"