Our transition to releasing every six weeks went really well. We're getting fixes to users much more quickly than we used to, but can we get fixes to users even faster? Moving to a five week cycle would mean a fix going into mozilla-central would get to users three weeks faster. That's a big deal. It's an upgrade in responsiveness that we can't afford to pass on if we can pull it off. I suspect the only way to know if we can do it is to try - we can always back off if it doesn't work out. I suspect the issues we'll face will be related to release quality and release/QA resources. Thoughts?
This is a great goal to strive for but I think there is a real risk of burnout until the process is more automated.
On 11-09-16 6:23 PM, Josh Aas wrote:
> Our transition to releasing every six weeks went really well. We're getting fixes to users much more quickly than we used to, but can we get fixes to users even faster? Moving to a five week cycle would mean a fix going into mozilla-central would get to users three weeks faster. That's a big deal. It's an upgrade in responsiveness that we can't afford to pass on if we can pull it off. I suspect the only way to know if we can do it is to try - we can always back off if it doesn't work out. I suspect the issues we'll face will be related to release quality and release/QA resources. Thoughts?
> _______________________________________________
> dev-planning mailing list
> dev-plann...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
-- Anthony Hughes
Mozilla QA Engineer
Automation, Releases, and Community
> Our transition to releasing every six weeks went really well. We're
> getting fixes to users much more quickly than we used to, but can we
> get fixes to users even faster? Moving to a five week cycle would
> mean a fix going into mozilla-central would get to users three weeks
> faster. That's a big deal. It's an upgrade in responsiveness that we
> can't afford to pass on if we can pull it off. I suspect the only way
> to know if we can do it is to try - we can always back off if it
> doesn't work out. I suspect the issues we'll face will be related to
> release quality and release/QA resources. Thoughts?
There is more than enough carping about the 6 week cycle being much too short. It might be better to wait a while until people become convinced that every update isn't going to break all their extensions, and plugins, and themes, and change the UI beyond recognition (as FF3 to FF4 did).
Yes, I absolutely think in the future we will shorten the cycle--but it won't be soon. We have some work to do to make 6 weeks smooth from a process, tool, and product side.
When we get 6 weeks down to a science we can shorten as needed. Note we will need to be very, very crisp on the messaging and announce the shift well in advance. Two of the major benefits of the process are predictability and consistency.
Thanks,
Christian
On Sep 16, 2011, at 6:59 PM, Ron Hunter <rphun...@charter.net> wrote:
> On 9/16/2011 8:23 PM, Josh Aas wrote:
>> Our transition to releasing every six weeks went really well. We're
>> getting fixes to users much more quickly than we used to, but can we
>> get fixes to users even faster? Moving to a five week cycle would
>> mean a fix going into mozilla-central would get to users three weeks
>> faster. That's a big deal. It's an upgrade in responsiveness that we
>> can't afford to pass on if we can pull it off. I suspect the only way
>> to know if we can do it is to try - we can always back off if it
>> doesn't work out. I suspect the issues we'll face will be related to
>> release quality and release/QA resources. Thoughts?
> There is more than enough carping about the 6 week cycle being much too short. It might be better to wait a while until people become convinced that every update isn't going to break all their extensions, and plugins, and themes, and change the UI beyond recognition (as FF3 to FF4 did).
> _______________________________________________
> dev-planning mailing list
> dev-plann...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Another +1. In webdev we love deploying fixes immediately to users, but
let's find all the painpoints (do we have a list) of the current process.
It's effecting us internally and externally. Once we've ironed those out,
by all means, let's ship as fast as possible. I'd even say, let's kill off
some channels if we have to.
-d
On Fri, Sep 16, 2011 at 7:21 PM, Christian Legnitto
<clegni...@mozilla.com>wrote:
> Yes, I absolutely think in the future we will shorten the cycle--but it
> won't be soon. We have some work to do to make 6 weeks smooth from a
> process, tool, and product side.
> When we get 6 weeks down to a science we can shorten as needed. Note we
> will need to be very, very crisp on the messaging and announce the shift
> well in advance. Two of the major benefits of the process are predictability
> and consistency.
> Thanks,
> Christian
> On Sep 16, 2011, at 6:59 PM, Ron Hunter <rphun...@charter.net> wrote:
> > On 9/16/2011 8:23 PM, Josh Aas wrote:
> >> Our transition to releasing every six weeks went really well. We're
> >> getting fixes to users much more quickly than we used to, but can we
> >> get fixes to users even faster? Moving to a five week cycle would
> >> mean a fix going into mozilla-central would get to users three weeks
> >> faster. That's a big deal. It's an upgrade in responsiveness that we
> >> can't afford to pass on if we can pull it off. I suspect the only way
> >> to know if we can do it is to try - we can always back off if it
> >> doesn't work out. I suspect the issues we'll face will be related to
> >> release quality and release/QA resources. Thoughts?
> > There is more than enough carping about the 6 week cycle being much too
> short. It might be better to wait a while until people become convinced
> that every update isn't going to break all their extensions, and plugins,
> and themes, and change the UI beyond recognition (as FF3 to FF4 did).
> > _______________________________________________
> > dev-planning mailing list
> > dev-plann...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-planning > _______________________________________________
> dev-planning mailing list
> dev-plann...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
> Our transition to releasing every six weeks went really well. We're getting fixes to users much more quickly than we used to, but can we get fixes to users even faster? Moving to a five week cycle would mean a fix going into mozilla-central would get to users three weeks faster. That's a big deal. It's an upgrade in responsiveness that we can't afford to pass on if we can pull it off. I suspect the only way to know if we can do it is to try - we can always back off if it doesn't work out. I suspect the issues we'll face will be related to release quality and release/QA resources. Thoughts?
At least for l10n, there's a lower limit in terms of volunteers being on vacation for some european-style-university time off.
Also, I wonder why we'd cut by a week? Like, I would rather understand what in the current process makes us believe that a different rhythm is better rather than trying to cut out one week every now and then and see if we survive.
We have a list of pain points and benefits and I will be articulating them in the coming weeks with various blog posts and videos. We've been doing a horrible job communicating about them and I intend to fix that (as it is mainly my fault).
Also, the channels were structured to produce quality software without slowing development. The current channels align quality, stability, and development goals with user testing, product expectations, and feedback collection mechanisms. I believe removing a channel upsets that balance and provides the wrong incentives, sets incorrect expectations, and introduces lots of quality risk.
Thanks,
Christian
On Sep 16, 2011, at 7:42 PM, Dave Dash <d...@mozilla.com> wrote:
> Another +1. In webdev we love deploying fixes immediately to users, but let's find all the painpoints (do we have a list) of the current process. It's effecting us internally and externally. Once we've ironed those out, by all means, let's ship as fast as possible. I'd even say, let's kill off some channels if we have to.
> -d
> On Fri, Sep 16, 2011 at 7:21 PM, Christian Legnitto <clegni...@mozilla.com> wrote:
> Yes, I absolutely think in the future we will shorten the cycle--but it won't be soon. We have some work to do to make 6 weeks smooth from a process, tool, and product side.
> When we get 6 weeks down to a science we can shorten as needed. Note we will need to be very, very crisp on the messaging and announce the shift well in advance. Two of the major benefits of the process are predictability and consistency.
> Thanks,
> Christian
> On Sep 16, 2011, at 6:59 PM, Ron Hunter <rphun...@charter.net> wrote:
> > On 9/16/2011 8:23 PM, Josh Aas wrote:
> >> Our transition to releasing every six weeks went really well. We're
> >> getting fixes to users much more quickly than we used to, but can we
> >> get fixes to users even faster? Moving to a five week cycle would
> >> mean a fix going into mozilla-central would get to users three weeks
> >> faster. That's a big deal. It's an upgrade in responsiveness that we
> >> can't afford to pass on if we can pull it off. I suspect the only way
> >> to know if we can do it is to try - we can always back off if it
> >> doesn't work out. I suspect the issues we'll face will be related to
> >> release quality and release/QA resources. Thoughts?
> > There is more than enough carping about the 6 week cycle being much too short. It might be better to wait a while until people become convinced that every update isn't going to break all their extensions, and plugins, and themes, and change the UI beyond recognition (as FF3 to FF4 did).
> > _______________________________________________
> > dev-planning mailing list
> > dev-plann...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-planning > _______________________________________________
> dev-planning mailing list
> dev-plann...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
> Our transition to releasing every six weeks went really well. We're getting fixes to users much more quickly than we used to, but can we get fixes to users even faster? Moving to a five week cycle would mean a fix going into mozilla-central would get to users three weeks faster. That's a big deal. It's an upgrade in responsiveness that we can't afford to pass on if we can pull it off. I suspect the only way to know if we can do it is to try - we can always back off if it doesn't work out. I suspect the issues we'll face will be related to release quality and release/QA resources. Thoughts?
1) It would place a bigger burden in the add-on compatibility bump process, which I'm handling.
2) It would place a bigger burden in add-on developers, who have to update their add-on already too often. Jetpack is not a magical solution for this, by the way.
3) It would place a bigger burden to the (partly) volunteer amo-editor team, who review the add-ons and add-on updates submitted to the site. We're already far below expectations because the rapid release cycle is drowning us in update submissions. We're working on picking up the pace, but increasing the update rate would quickly overtake any efforts we're making in this area.
> Our transition to releasing every six weeks went really well. We're
> getting fixes to users much more quickly than we used to
[...]
I think how well it went is arguable. Getting some stuff to some users faster is good, but it shouldn't be the only goal. Only around two thirds of Firefox users are on Firefox 5/6/7.
If you wanted to really speed things up, instead of cutting the cycle to 5 weeks, why not cut out a channel and go straight from what is now aurora to release? That's 6 weeks faster, with less switches.
Thanks for the replies. I'm happy to hear that people are keeping track of and working on the things that we need to accomplish to release even faster.
On Sep 17, 2011, at 3:40 AM, Michael Lefevre <mjl+n...@michaellefevre.com> wrote:
> On 17/09/2011 02:23, Josh Aas wrote:
>> Our transition to releasing every six weeks went really well. We're
>> getting fixes to users much more quickly than we used to
> [...]
> I think how well it went is arguable. Getting some stuff to some users faster is good, but it shouldn't be the only goal. Only around two thirds of Firefox users are on Firefox 5/6/7.
> If you wanted to really speed things up, instead of cutting the cycle to 5 weeks, why not cut out a channel and go straight from what is now aurora to release? That's 6 weeks faster, with less switches.
FYI, it has been a success when you look at use. Of course there are still some issues we need to smooth over--most of which involve 3rd parties.
The reason we "only" have 2/3rds is we haven't pulled our big lever (prompt 3.6 users to update). We will be doing so soon and 3.6 will disappear weeks after. Firefox 4 is close to what we consider "dead" and dropping.
This sort of stuff is what I'll be talking about and making clear in the coming weeks.
I already expressed my general feeling about cutting out a channel and hope my posts/videos in the coming weeks will make it clear.
I also want to note we have only released *one* update in the new process (Firefox 6). Firefox 5 was a quarter after 4 and didn't have all the overlapping, etc. I don't want us to prematurely optimize or declare success/failure. We're still figuring out how to measure what we need to, if what we are measuring will naturally change over time, etc.
I agree, its way to early to shorten this. While the add-on compatibility bump might relieve some addon developers, those with binary components are going to crash and burn.
For me, developing the Lightning add-on, managing releases between university work and actually writing patches is a strong burden. We are working on improving release automation which may make this okay, but since we have a binary component on board this means 3 AMO reviews (one per platform) just for Lightning.
Also, while a short release cycle might be good for Firefox that has a lot of QA on the beta and nightly channel, think of how this works for extensions. The QA community is much smaller and is additionally split up on 2-3 different channels. This means a small amount of QA, so it takes longer to find all issues. The shorter the cycle, the more bugs will go through into the release, the more quality will decrease, which will indirectly burden the app...you see where I am going here?
It may take a while for us to get used to the already short release cycle, but please remember, if you do it for Firefox, then you are implicitly doing it for the whole Mozilla ecosystem. Give us a break, take your time until you introduce 5 or less weeks.
On Sat, Sep 17, 2011 at 8:49 PM, Christian Legnitto
<clegni...@mozilla.com> wrote:
> The reason we "only" have 2/3rds is we haven't pulled our big lever (prompt 3.6 users to update).
> We will be doing so soon and 3.6 will disappear weeks after.
I rather hope the big lever doesn't get pulled before we have silent
update. People who are still sticking to 3.6 are either people who
aren't proactive about seeking new versions or are knowingly sticking
to something old due to add-on or intranet compat. If we move that
kinds of users forward but without silent update to keep moving them
forward continuously, there's a risk of creating a more scattered tail
of users on non-latest release.
> Firefox 4 is close to what we consider "dead" and dropping.
What I'm hearing from my Web developer friends is that their customers
still expect QA with Firefox 4 and 5, because we aren't doing good
enough a job at making old releases disappear from circulation. That
is, Web developers don't consider Firefox 4 "dead", yet. While moving
the platform forward rapidly is nice for Web developers, having a
scattered tail of non-latest releases in use is not nice for Web
developers.
Thanks to silent update and a forward-compatible extension API, Chrome
does such a good job at taking old releases out of circulation that
Web developers genuinely don't worry about old releases of Chrome. To
get Web developer mind share from Rapid Release, we not only need to
deliver new features sooner but we also need to clean up old releases
more effectively. At least 3.6 is a clearer QA target for Web
developers than a scattered tail of users on various non-latest
releases.
> Our transition to releasing every six weeks went really well. We're getting fixes to users much more quickly than we used to, but can we get fixes to users even faster? Moving to a five week cycle would mean a fix going into mozilla-central would get to users three weeks faster. That's a big deal. It's an upgrade in responsiveness that we can't afford to pass on if we can pull it off. I suspect the only way to know if we can do it is to try - we can always back off if it doesn't work out. I suspect the issues we'll face will be related to release quality and release/QA resources. Thoughts?
We already only have ~5 weeks on Beta (as we release 6 weeks after going to beta and need to create the release builds roughly a week before release to allow for enough QA), and that's the only place where we can get really good data on crashes due to ADU volumes. Also, it takes us ~1 week after going to the beta channel before we get good data (at least 1 day until we have builds, 1-2 days until we have QA to push it to the beta channel, 2-3 days for uptake, need 1, better at least 2 days of data to tell anything reasonable). That means that right now we already only have around 4 weeks with roughly the same amount of builds to analyze and react to crash data as well as other beta feedback.
I'm not sure how much we can tighten that up in the future, but right now I don't see us able to do that. Let's first get really used to the new cycle and improve stability.
Robert Kaiser
-- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community needs answers to. And most of the time, I even appreciate irony and fun! :)
> On Sat, Sep 17, 2011 at 8:49 PM, Christian Legnitto
> <clegni...@mozilla.com> wrote:
>> The reason we "only" have 2/3rds is we haven't pulled our big lever (prompt 3.6 users to update).
>> We will be doing so soon and 3.6 will disappear weeks after.
> I rather hope the big lever doesn't get pulled before we have silent
> update.
We aren't waiting that long. The good news is installing via the pop-up is opt-in, just like Major Update offers have always been.
> People who are still sticking to 3.6 are either people who
> aren't proactive about seeking new versions or are knowingly sticking
> to something old due to add-on or intranet compat. If we move that
> kinds of users forward but without silent update to keep moving them
> forward continuously, there's a risk of creating a more scattered tail
> of users on non-latest release.
Yes, this is a risk that has been discussed. Also, "silent update" is a fairly loaded term that talks about an umbrella of work. We need to stop using it and to instead talk specifically about what we mean. For example, "silent update" as it is generally discussed doesn't mean silent when the user has incompatible add-ons[1]. Also, we are making updates more "silent" in Firefox 7 by not opening a new tab after an update....it's not what people generally mean by silent update but it helps nonetheless[2].
[1] Note that there are other projects in flight to make add-ons compatible, which would make updates more silent
[2] There is actually support in product for us to specify behavior in the update snippets, AUS server-side support isn't there yet
>> Firefox 4 is close to what we consider "dead" and dropping.
> What I'm hearing from my Web developer friends is that their customers
> still expect QA with Firefox 4 and 5, because we aren't doing good
> enough a job at making old releases disappear from circulation. That
> is, Web developers don't consider Firefox 4 "dead", yet. While moving
> the platform forward rapidly is nice for Web developers, having a
> scattered tail of non-latest releases in use is not nice for Web
> developers.
I think this is an education problem rather than a numbers problem. The scattered tail (I like to use the term "update stratification") is a real concern that we are watching. We just have to see how it plays out, I'm actually pretty happy with the current update numbers even though we have done nothing to ease painpoints yet (like the what's new tab suppression coming in Firefox 7). I haven't dug in and down a meaty analysis though.
> Thanks to silent update and a forward-compatible extension API, Chrome
> does such a good job at taking old releases out of circulation that
> Web developers genuinely don't worry about old releases of Chrome. To
> get Web developer mind share from Rapid Release, we not only need to
> deliver new features sooner but we also need to clean up old releases
> more effectively. At least 3.6 is a clearer QA target for Web
> developers than a scattered tail of users on various non-latest
> releases.
Chrome had the luxury of following and setting new expectations from day 1. We're changing, it just takes some time. We turned on a dime (relatively) and it will take a bit for some engineering work to catch up. I think our current numbers (Firefox 6 @ over 50%, Firefox 5 @ under 10%, Firefox 4 @ under 5%) look decent to good but we of course intend to improve them. Our uptake got quicker between Firefox 5 and 6 as well, which is great, hopefully the trend continues for Firefox 7.
Web developers should in general see no difference except for new features and fixes between Firefox 4/5/6 (they are doing feature detection, right?). Additionally, it's pretty manageable to compare changes in Firefox versions these days--largely thanks to the new release process:
FWIW I also want us to loop back around and do a refreshed update for Firefox 3.0 and 3.5 users once AUS has nicer wildcard support (I hear soon!). I don't like that their numbers in absolute terms are high. 3.0's can be attributed to our old EOL policy (that is, no automatic update at the end of the road).
3.6 is obsolete when compared with a modern Firefox and soon it will have the user numbers to back it up. Most 3.6 users don't even know there is an update so they will take the offer pop-up (though the % should be interesting w.r.t add-on compatibility and the refreshed UI...we're watching closely).
On Mon, Sep 19, 2011 at 9:13 AM, Christian Legnitto
<clegni...@mozilla.com> wrote: > On Sep 18, 2011, at 7:30 AM, Henri Sivonen wrote: >> I rather hope the big lever doesn't get pulled before we have silent >> update.
> We aren't waiting that long. The good news is installing via the pop-up is opt-in, just like Major Update offers have always been.
Opt-in not "good news" from the Web developer point of view, because giving users choice means they'll scatter across more versions. (But yeah, I realize it would be bad for some user-side scenarios for this not to be opt-in.)
>>> Firefox 4 is close to what we consider "dead" and dropping.
>> What I'm hearing from my Web developer friends is that their customers >> still expect QA with Firefox 4 and 5, because we aren't doing good >> enough a job at making old releases disappear from circulation. That >> is, Web developers don't consider Firefox 4 "dead", yet. While moving >> the platform forward rapidly is nice for Web developers, having a >> scattered tail of non-latest releases in use is not nice for Web >> developers.
> I think this is an education problem rather than a numbers problem.
Education problem in the sense of educating users or educating Web developers? It's a numbers problem in the sense that as long as a Firefox version shows up in StatCounter's top 12 browser version list globally or for the Web developer's country, the version isn't considered "dead" yet.
> Web developers should in general see no difference except for new features and > fixes between Firefox 4/5/6 (they are doing feature detection, right?).
The thing is that the developers or their customers aren't confident enough in this that they'd skip testing older releases. Even if feature detection is used, having to (i.e. feeling to having to) test with a bunch of releases is causing unhappiness. After all, you don't know for *sure* there's no difference before you've done the testing.
> On Sep 18, 2011, at 7:30 AM, Henri Sivonen wrote:
>> On Sat, Sep 17, 2011 at 8:49 PM, Christian Legnitto
>> <clegni...@mozilla.com> wrote:
>>> The reason we "only" have 2/3rds is we haven't pulled our big lever (prompt 3.6 users to update).
>>> We will be doing so soon and 3.6 will disappear weeks after.
>> I rather hope the big lever doesn't get pulled before we have silent
>> update.
> We aren't waiting that long. The good news is installing via the pop-up is opt-in, just like Major Update offers have always been.
>> People who are still sticking to 3.6 are either people who
>> aren't proactive about seeking new versions or are knowingly sticking
>> to something old due to add-on or intranet compat. If we move that
>> kinds of users forward but without silent update to keep moving them
>> forward continuously, there's a risk of creating a more scattered tail
>> of users on non-latest release.
> Yes, this is a risk that has been discussed. Also, "silent update" is a fairly loaded term that talks about an umbrella of work. We need to stop using it and to instead talk specifically about what we mean. For example, "silent update" as it is generally discussed doesn't mean silent when the user has incompatible add-ons[1]. Also, we are making updates more "silent" in Firefox 7 by not opening a new tab after an update....it's not what people generally mean by silent update but it helps nonetheless[2].
> [1] Note that there are other projects in flight to make add-ons compatible, which would make updates more silent
> [2] There is actually support in product for us to specify behavior in the update snippets, AUS server-side support isn't there yet
>>> Firefox 4 is close to what we consider "dead" and dropping.
>> What I'm hearing from my Web developer friends is that their customers
>> still expect QA with Firefox 4 and 5, because we aren't doing good
>> enough a job at making old releases disappear from circulation. That
>> is, Web developers don't consider Firefox 4 "dead", yet. While moving
>> the platform forward rapidly is nice for Web developers, having a
>> scattered tail of non-latest releases in use is not nice for Web
>> developers.
> I think this is an education problem rather than a numbers problem. The scattered tail (I like to use the term "update stratification") is a real concern that we are watching. We just have to see how it plays out, I'm actually pretty happy with the current update numbers even though we have done nothing to ease painpoints yet (like the what's new tab suppression coming in Firefox 7). I haven't dug in and down a meaty analysis though.
>> Thanks to silent update and a forward-compatible extension API, Chrome
>> does such a good job at taking old releases out of circulation that
>> Web developers genuinely don't worry about old releases of Chrome. To
>> get Web developer mind share from Rapid Release, we not only need to
>> deliver new features sooner but we also need to clean up old releases
>> more effectively. At least 3.6 is a clearer QA target for Web
>> developers than a scattered tail of users on various non-latest
>> releases.
> Chrome had the luxury of following and setting new expectations from day 1. We're changing, it just takes some time. We turned on a dime (relatively) and it will take a bit for some engineering work to catch up. I think our current numbers (Firefox 6 @ over 50%, Firefox 5 @ under 10%, Firefox 4 @ under 5%) look decent to good but we of course intend to improve them. Our uptake got quicker between Firefox 5 and 6 as well, which is great, hopefully the trend continues for Firefox 7.
> Web developers should in general see no difference except for new features and fixes between Firefox 4/5/6 (they are doing feature detection, right?).
We need to stop saying this. First off "new features and fixes" do
break existing sites. Sometimes because these new features share
namespace with webpages JS code and so collisions break code. Other
times because pages accidentally rely on the bugs that the fixes fix.
There are absolutely changes going into the quick releases which are
not 100% backwards compatible. There's a big push in standards bodies
right now to tighten the differences between edge cases in browser
DOMs. These are good changes and long term will make it easier for
developers to make code work cross browser. However in the meantime
developers have to deal with potentially breaking changes in browser
behavior.
And unfortunately feature detection is no silver bullet. For newly
introduced features colliding to to shared namespaces, and for
bugfixes mentioned above, it doesn't help at all. And even when it's
possible to use in theory, other browsers have a habit of introducing
features in a fashion that breaks the ability to use feature
detection.
>> We will be doing so soon and 3.6 will disappear weeks after.
> I rather hope the big lever doesn't get pulled before we have silent > update.
The 3.6.x update experience is what it is. No amount of work on silent updates on mozilla-central will make 3.6 updates any more silent; we buy nothing by waiting.
> Our transition to releasing every six weeks went really well. We're getting fixes to users much more quickly than we used to, but can we get fixes to users even faster? Moving to a five week cycle would mean a fix going into mozilla-central would get to users three weeks faster. That's a big deal. It's an upgrade in responsiveness that we can't afford to pass on if we can pull it off. I suspect the only way to know if we can do it is to try - we can always back off if it doesn't work out. I suspect the issues we'll face will be related to release quality and release/QA resources. Thoughts?
Speaking as the lead FF engineer for a third-party corporation: Please, no! We've got so much maintenance work as it is keeping our products updated right now. We haven't been able to catch a break, and it's eating up one engineer's full time already. (Specifically, mine, and I'm no slouch.)
On paper, it sounds nice, but in the dirty, messy real world, the six-week cycle is already a much larger than expected drain on our resources. We've already had some close calls because of the rapid cycle; going to five weeks would practically ensure we could not keep up.
On Mon, Sep 19, 2011 at 8:08 PM, Daniel Veditz <dved...@mozilla.com> wrote:
> On 9/18/11 7:30 AM, Henri Sivonen wrote:
>>> We will be doing so soon and 3.6 will disappear weeks after.
>> I rather hope the big lever doesn't get pulled before we have silent
>> update.
> The 3.6.x update experience is what it is. No amount of work on
> silent updates on mozilla-central will make 3.6 updates any more
> silent; we buy nothing by waiting.
I meant silent update onwards from whatever is offered to 3.6 users.
(That is, if we offered Firefox 11 to 3.6 users as a prompted update,
I'd hope the update from Firefox 11 to 12 was silent.)
This thread got turned into a bogus "news" article via conceivablytech and
Slashdot.
It does raise the question though: maybe we should slow down our release
cycle, while we work out the problems with addon compatibility and our
updater?
Rob
-- "If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]
> This thread got turned into a bogus "news" article via conceivablytech and
> Slashdot.
> It does raise the question though: maybe we should slow down our release
> cycle, while we work out the problems with addon compatibility and our
> updater?
This thread is not changing the schedule of Firefox releases. This thread is people talking about stuff.
Any future change to our schedules will be loudly communicated. We know that lots of people are quite keenly interested in the particulars. More updates as events warrant.
Headline editors, you do keep our lives full of mirth, thanks for that.
Johnathan
---
Johnathan Nightingale
Director of Firefox Engineering
john...@mozilla.com
Since this is becoming a hot news item, would it be feasible to re-explain in this thread why the rapid release cycle?
There's a lot of . . . disappointment . . . for the route that firefox has taken and I believe that some public relations work need to be done. A good start is explaining why the rapid release, when you already had a good, solid product used by many. How are you working with add-on/extension developers to ensure that their products are not invalidated with each new release. Explain about websites that used to work with firefox, that are now broken, is there anything being done about this, or is there a process to call attention to these problems to get them fixed.
As much as I like firefox for what it was, these new release cycles have discouraged me for the future of firefox.
See Johnath's previous message. This thread is about people talking about
stuff. That's how Mozilla works - we discuss in the open. Please don't ask
us to rehash previous discussions at the cost of derailing current ones.
The previous decision has had blog posts and previous topics in this forum.
Search functions await your input!
cheers,
mike
On 20/09/2011 5:30 PM, <barrywaldbil...@gmail.com> wrote:
> Since this is becoming a hot news item, would it be feasible to re-explain
in this thread why the rapid release cycle?
> There's a lot of . . . disappointment . . . for the route that firefox has
taken and I believe that some public relations work need to be done. A good
start is explaining why the rapid release, when you already had a good,
solid product used by many. How are you working with add-on/extension
developers to ensure that their products are not invalidated with each new
release. Explain about websites that used to work with firefox, that are now
broken, is there anything being done about this, or is there a process to
call attention to these problems to get them fixed.
> As much as I like firefox for what it was, these new release cycles have
