A five week release cycle?

2728 views
Skip to first unread message

Josh Aas

unread,
Sep 16, 2011, 9:23:59 PM9/16/11
to
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?

Anthony Hughes

unread,
Sep 16, 2011, 9:46:36 PM9/16/11
to dev-pl...@lists.mozilla.org
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-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning


--
Anthony Hughes
Mozilla QA Engineer
Automation, Releases, and Community

Ron Hunter

unread,
Sep 16, 2011, 9:59:18 PM9/16/11
to
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).

Christian Legnitto

unread,
Sep 16, 2011, 10:20:57 PM9/16/11
to Ron Hunter, dev-pl...@lists.mozilla.org
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

Dave Dash

unread,
Sep 16, 2011, 10:42:57 PM9/16/11
to Christian Legnitto, dev-pl...@lists.mozilla.org, Ron Hunter
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
<cleg...@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 <rphu...@charter.net> wrote:
>

Axel Hecht

unread,
Sep 16, 2011, 10:55:12 PM9/16/11
to
On 16.09.11 18: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, 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.

Axel

Christian Legnitto

unread,
Sep 16, 2011, 10:56:57 PM9/16/11
to Dave Dash, dev-pl...@lists.mozilla.org, Ron Hunter
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 <cleg...@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 <rphu...@charter.net> wrote:
>

Jorge Villalobos

unread,
Sep 17, 2011, 3:45:54 AM9/17/11
to mozilla.de...@googlegroups.com, Josh Aas
On 9/16/11 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?

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.

- Jorge

Michael Lefevre

unread,
Sep 17, 2011, 6:40:30 AM9/17/11
to
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.

Michael

Josh Aas

unread,
Sep 17, 2011, 12:58:13 PM9/17/11
to
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.

Christian Legnitto

unread,
Sep 17, 2011, 1:49:15 PM9/17/11
to Michael Lefevre, dev-pl...@lists.mozilla.org
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.

Thanks,
Christian

kew...@gmail.com

unread,
Sep 17, 2011, 4:06:04 PM9/17/11
to
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.

Philipp

Henri Sivonen

unread,
Sep 18, 2011, 10:30:04 AM9/18/11
to dev-pl...@lists.mozilla.org
On Sat, Sep 17, 2011 at 8:49 PM, Christian Legnitto
<cleg...@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.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

Robert Kaiser

unread,
Sep 19, 2011, 12:50:06 AM9/19/11
to
Josh Aas schrieb:
> 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! :)

Christian Legnitto

unread,
Sep 19, 2011, 2:13:27 AM9/19/11
to Henri Sivonen, dev-pl...@lists.mozilla.org

On Sep 18, 2011, at 7:30 AM, Henri Sivonen wrote:

> On Sat, Sep 17, 2011 at 8:49 PM, Christian Legnitto
> <cleg...@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:

* https://developer.mozilla.org/en/Firefox_5_for_developers
* https://developer.mozilla.org/en/Firefox_6_for_developers
* https://developer.mozilla.org/en/Firefox_7_for_developers

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).

Thanks,
Christian

Henri Sivonen

unread,
Sep 19, 2011, 4:08:32 AM9/19/11
to dev-pl...@lists.mozilla.org
On Mon, Sep 19, 2011 at 9:13 AM, Christian Legnitto
<cleg...@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.

Jonas Sicking

unread,
Sep 19, 2011, 4:16:00 AM9/19/11
to Christian Legnitto, Henri Sivonen, dev-pl...@lists.mozilla.org
On Sun, Sep 18, 2011 at 11:13 PM, Christian Legnitto
<cleg...@mozilla.com> wrote:
>
> On Sep 18, 2011, at 7:30 AM, Henri Sivonen wrote:
>
>> On Sat, Sep 17, 2011 at 8:49 PM, Christian Legnitto
>> <cleg...@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.

/ Jonas

Daniel Veditz

unread,
Sep 19, 2011, 1:08:16 PM9/19/11
to dev-pl...@lists.mozilla.org
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.

-Dan Veditz

Alex Vincent

unread,
Sep 19, 2011, 1:19:34 PM9/19/11
to
On 9/16/2011 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?

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.

Alex Vincent
APN, LLC

Henri Sivonen

unread,
Sep 19, 2011, 2:30:17 PM9/19/11
to dev-pl...@lists.mozilla.org
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.)

Robert O'Callahan

unread,
Sep 20, 2011, 5:57:59 PM9/20/11
to dev-pl...@lists.mozilla.org
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]

Schalk Neethling

unread,
Sep 20, 2011, 6:00:24 PM9/20/11
to rob...@ocallahan.org, dev-pl...@lists.mozilla.org
On 20/09/2011 23:57, Robert O'Callahan wrote:
> 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
Hey Rob,

ExtremeTech is running an article about this as well:
http://www.extremetech.com/mobile/96737-mozilla-wants-to-shorten-firefoxs-six-week-release-schedule-to-five-weeks-or-less

Schalk

Johnathan Nightingale

unread,
Sep 20, 2011, 6:06:20 PM9/20/11
to mozilla.dev.planning group
On 2011-09-20, at 6:00 PM, Schalk Neethling wrote:
> On 20/09/2011 23:57, Robert O'Callahan wrote:
>> This thread got turned into a bogus "news" article via conceivablytech and
>> Slashdot.
> ...
Hello newcomers,

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
joh...@mozilla.com



barrywa...@gmail.com

unread,
Sep 20, 2011, 6:25:06 PM9/20/11
to mozilla.dev.planning group
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.

Thanks, B.

beltzner

unread,
Sep 20, 2011, 7:07:27 PM9/20/11
to mozilla.de...@googlegroups.com, mozilla.dev.planning group
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

David Mandelin

unread,
Sep 20, 2011, 7:22:08 PM9/20/11
to
On 9/20/2011 2:57 PM, Robert O'Callahan wrote:
> 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?

I've been thinking about those things as well. I would say that if we
are going to keep the 6-week pace, at least silent update and fixing
add-on compatibility should be top-priority work.

I'm not sure what we're planning for enterprise support at this point,
but that seems like another important thing that needs to be fixed if we
are going to keep releasing much more often than annually.

Dave

Robert Strong

unread,
Sep 20, 2011, 7:31:44 PM9/20/11
to dev-pl...@lists.mozilla.org

On 9/20/2011 4:22 PM, David Mandelin wrote:
> On 9/20/2011 2:57 PM, Robert O'Callahan wrote:
>> 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?
> I've been thinking about those things as well. I would say that if we
> are going to keep the 6-week pace, at least silent update and fixing
> add-on compatibility should be top-priority work.
We formed a team / had our first meeting last week to focus on silent
updates and it is definitely a top priority. You can see some of the
planned work on the desktop features page.
https://wiki.mozilla.org/Features/Desktop

>
> I'm not sure what we're planning for enterprise support at this point,
> but that seems like another important thing that needs to be fixed if we
> are going to keep releasing much more often than annually.
There has been a lot of discussion around support for Firefox
deployments and hopefully resources will be allocated towards making
supporting deployments better though there haven't been as of yet as far
as I know.

> Dave
>
--
Cheers,
Robert Strong

Lawrence Mandel

unread,
Sep 20, 2011, 7:35:05 PM9/20/11
to David Mandelin, dev-pl...@lists.mozilla.org
Hi Dave,

Rest assured that there are people working on silent update, add-on compatibility, and enterprise support. Here are some links if you want more info or want to get involved in any of these efforts.

Silent update and add-on compatibility features (we're working on these now):
https://wiki.mozilla.org/Features/Desktop

Enterprise User Work Group
https://wiki.mozilla.org/Enterprise

Lawrence

Robert O'Callahan

unread,
Sep 20, 2011, 7:38:32 PM9/20/11
to Robert Strong, dev-pl...@lists.mozilla.org
On Wed, Sep 21, 2011 at 11:31 AM, Robert Strong <rst...@mozilla.com> wrote:

> We formed a team / had our first meeting last week to focus on silent
> updates and it is definitely a top priority. You can see some of the planned
> work on the desktop features page.
> https://wiki.mozilla.org/**Features/Desktop<https://wiki.mozilla.org/Features/Desktop>


That is very good. However I imagine that it will still be a while before
that work is ready to ship, especially since updater reliability is so
critical. Can we afford to keep doing rapid releases in the meantime?

This is up to product drivers. I assume they've thought this through
carefully already. I just want to be sure we don't have a "we never really
considered that" moment later.

Steve Wendt

unread,
Sep 20, 2011, 8:04:32 PM9/20/11
to
On 9/20/2011 4:31 PM, Robert Strong wrote:

>> I'm not sure what we're planning for enterprise support at this point,
>> but that seems like another important thing that needs to be fixed if we
>> are going to keep releasing much more often than annually.
> There has been a lot of discussion around support for Firefox
> deployments and hopefully resources will be allocated towards making
> supporting deployments better

Speaking of enterprise support - Asa has been rather silent lately. I
do miss his weekly summaries...

Joshua Cranmer

unread,
Sep 20, 2011, 8:38:07 PM9/20/11
to
On 9/20/2011 4:57 PM, Robert O'Callahan wrote:
> 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?

I do not know if this is related to the release cycle, but I have
noticed that the time it takes to get an addon reviewed seems to be
skyrocketing; my latest revision is still in the queue (only 42 out of
210!) after no fewer than 23 days...

Boris Zbarsky

unread,
Sep 20, 2011, 10:07:12 PM9/20/11
to
On 9/20/11 5:57 PM, Robert O'Callahan wrote:
> This thread got turned into a bogus "news" article via conceivablytech and
> Slashdot.

This is a surprise? :(

To be honest, it wasn't clear to me whether the original post in this
thread was even being serious or not... But it was pretty much
custom-designed to be taken out of context.

-Boris

Robert Strong

unread,
Sep 20, 2011, 11:14:40 PM9/20/11
to dev-pl...@lists.mozilla.org


On 9/20/2011 4:38 PM, Robert O'Callahan wrote:
> On Wed, Sep 21, 2011 at 11:31 AM, Robert Strong <rst...@mozilla.com
> <mailto:rst...@mozilla.com>> wrote:
>
> We formed a team / had our first meeting last week to focus on
> silent updates and it is definitely a top priority. You can see
> some of the planned work on the desktop features page.
> https://wiki.mozilla.org/Features/Desktop
>
>
> That is very good. However I imagine that it will still be a while
> before that work is ready to ship, especially since updater
> reliability is so critical. Can we afford to keep doing rapid releases
> in the meantime?
I don't think we have data either way that shows it to be a problem that
should make us reconsider rapid release at this time. There are also a
couple areas where we will be improving the current process. The most
immediate improvement that should have the largest impact is the add-on
compatibility work being done on AMO since if an add-on will be disabled
by the update the user has to opt-in to receiving the update whereas by
default the update will download in the background and be applied during
startup.

>
> This is up to product drivers. I assume they've thought this through
> carefully already. I just want to be sure we don't have a "we never
> really considered that" moment later.
Agreed wholeheartedly. One misconception I get a lot that I think falls
into "we never really considered that" is that silent updates will take
care of the add-on compatibility problem. In reality, the user will
still be warned unless the preference to check if add-ons will be
disabled by the update is set to disable the check. Any Mozilla
application can choose to ignore the check by default but that is just
the wrong approach to solving the problem.

Robert

Henri Sivonen

unread,
Sep 21, 2011, 3:21:29 AM9/21/11
to dev-pl...@lists.mozilla.org
On Wed, Sep 21, 2011 at 12:57 AM, Robert O'Callahan
<rob...@ocallahan.org> wrote:
> 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?

What are the current time estimates for getting Silent Update and
JetPack into Firefox? That is, for how long would we need to slow
down?

(It looks worrying that 9 months after we started thinking of a rapid
release process and 6 months after having a concrete process proposal,
the Silent Update feature page shows its status as "Planning".)

rx7c...@gmail.com

unread,
Sep 21, 2011, 5:30:10 AM9/21/11
to
If any Mozilla developers are even remotely interested in why this loyal FF user is about to leave..it's not because of too slow updating, it's because in the updates, I lose all my extensions and add ons faster than their programmers can keep up. Just want a stable FF that will manage Google Toolbar and SEO Quake. And FF is turning into the memory hog that IE is. Quit fixing it to death!

Michael Lefevre

unread,
Sep 21, 2011, 5:53:11 AM9/21/11
to
Seems it is related to the release cycle, and the queues have been
growing rapidly:
https://forums.mozilla.org/addons/viewtopic.php?f=21&t=3929

They've been looking for more people to help with reviews for a while:
http://blog.mozilla.com/addons/2011/05/04/join-us-help-reviewing-add-ons/

Michael

stz3...@gmail.com

unread,
Sep 21, 2011, 7:20:38 AM9/21/11
to
Dear Mozilla Developers

I love firefox and mostly everything around it, you surely got the best addons etc. BUT before you think about speeding up the release interval, please give us a solid and clean possibility to deploy and manage firefox in enterprise environments!! At home i don't have any problem about a fast or even faster release interval, but for it administrators its a real challenge to deploy and manage all the new versions every couple of weeks. Please make a solid msi package and msp update packages for Windows and the last little part which can make it perfect, would be the possiblity to manage the settings etc. via GPO's (group policies). AND do it yourself, don't count on third part developers to manage this... i don't trust all the different ways on the net to bring it into active directory or other ways of deployment, mostly they aren't up to date or missing some new functions or something...
At our enterprise, firefox still runs with v3.x because i don't have the time to test every new version and the deployment of it every couple of weeks. so if you want to keep your wide usage of firefox around the world and compete with IE, think about supporting IT Administrators in their work. IE9 / 10 is not as bad as the older versions were, so we'll maybe switch back to IE only if you don't help us keep it manageable. At home i love firefox, at work i hate it... and much users aren't willing to use 2 different browsers and if they just can't use firefox at work, i don't think they really consider to use it at home, so they don't have to get familiar with 2 browsers (clearly i talk about the simple users, not some sort of power user).
Simple: Please support enterprise deployment for active directory based environments, then it wouldn't be such a pain in the ass..embly :) Our users don't have admin rights of course, because they don't know what they're doing. ;)

beltzner

unread,
Sep 21, 2011, 7:59:33 AM9/21/11
to dev-pl...@lists.mozilla.org
Hi! This topic has been discussed thoroughly here, and ongoing
discussion has been moved to a separate working group / mailing list
until solid proposals and plans are in place.

Please see https://wiki.mozilla.org/Enterprise and the associated
mailing list for plans on working with Enterprise deployments.

cheers,
mike

Dao

unread,
Sep 21, 2011, 8:22:07 AM9/21/11
to
On 21.09.2011 11:53, Michael Lefevre wrote:
>>> 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?
>>
>> I do not know if this is related to the release cycle, but I have
>> noticed that the time it takes to get an addon reviewed seems to be
>> skyrocketing; my latest revision is still in the queue (only 42 out of
>> 210!) after no fewer than 23 days...
>
> Seems it is related to the release cycle, and the queues have been
> growing rapidly:
> https://forums.mozilla.org/addons/viewtopic.php?f=21&t=3929
>
> They've been looking for more people to help with reviews for a while:
> http://blog.mozilla.com/addons/2011/05/04/join-us-help-reviewing-add-ons/

Maybe we should hold back non-critical updates until the "Full Review
Updates" queue is down to zero?

Gijs Kruitbosch

unread,
Sep 21, 2011, 8:33:34 AM9/21/11
to
Isn't the problem that for every update that rolls out (ie every 6 weeks), a new
mass of 'critical' ("Without this update, my add-on breaks in Firefox.next")
add-on updates starts?

I don't think that's something that can be fixed by any kind of temporary stop
on some types of reviews - only by adding reviewers, or by somehow making it
easier for add-on authors to stay compatible (through the automatic compat
marking, and/or jetpack, and/or breaking fewer APIs on which lots of add-ons rely).

Gijs

Dao

unread,
Sep 21, 2011, 8:52:57 AM9/21/11
to
On 21.09.2011 14:33, Gijs Kruitbosch wrote:
> On 21/09/2011 14:22 PM, Dao wrote:
>> On 21.09.2011 11:53, Michael Lefevre wrote:
>>>>> 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?
>>>>
>>>> I do not know if this is related to the release cycle, but I have
>>>> noticed that the time it takes to get an addon reviewed seems to be
>>>> skyrocketing; my latest revision is still in the queue (only 42 out of
>>>> 210!) after no fewer than 23 days...
>>>
>>> Seems it is related to the release cycle, and the queues have been
>>> growing rapidly:
>>> https://forums.mozilla.org/addons/viewtopic.php?f=21&t=3929
>>>
>>> They've been looking for more people to help with reviews for a while:
>>> http://blog.mozilla.com/addons/2011/05/04/join-us-help-reviewing-add-ons/
>>>
>>
>> Maybe we should hold back non-critical updates until the "Full Review
>> Updates"
>> queue is down to zero?
>
> Isn't the problem that for every update that rolls out (ie every 6
> weeks), a new mass of 'critical' ("Without this update, my add-on breaks
> in Firefox.next") add-on updates starts?

I'm talking about non-critical Firefox updates.

raphael...@googlemail.com

unread,
Sep 21, 2011, 10:31:57 AM9/21/11
to
(Please excuse my bad english - I'am a German one)


I fully agree with you stz3. A better enterprise support would be great.

But for this topic there is another very important point, which must be considered: the psychologic side.
If this release-cycle is hold, more and more consumers switch to other browsers. Why? There are a couple of reasons:

1. Many users are affraid, that their Add-Ons are not compatible
2. The fast increase of the major version number "hustle" the users and developers at the cost of security, care and functionality which results in a worse browser.
3. Also the fast increase makes a joke out of this politic. Here in Germany some people already tell it a "running Firegag" (analog to: "running Gag").
4. Additionally a new bigger major-number let the users think, that there are more new features as their can be implemented in the short time.

Furthermore many people would even wait longer, and had a better tested browser, and much more features with a big release numbers instead of this version-ralley.

For sure - security problems should be fixed as soon as possible, but this could be done with minor-patches. Also little changes could be implemented in an minor release. (e.g. version-number 4.0 to 4.5)

Also the fast cycle is more work for the core-developer of firefox, which can also result in less care and security problems (the "hustle-problem").

So the question is:
Is the fast increase of the major version-number really needed? Can't it be replaced by minor-numbers, and every half-year (or a hole year) a bigger release? (and if it only be done for the psychologic of humans)


Overall the fast release-cycle is contraproductive for all: Consumers, extension-developers, and core-developers.


Best regards
Raphael

wgru...@gmail.com

unread,
Sep 21, 2011, 10:51:50 AM9/21/11
to dev-pl...@lists.mozilla.org, rob...@ocallahan.org
Rob,

I suggest that you read our article before you make such a public statement. We have never reported on your 5-week release cycle, but on the fact that Firefox market share is in a decline.

You may want to get your sources right.

Wolfgang

Jorge Villalobos

unread,
Sep 21, 2011, 11:21:13 AM9/21/11
to Dao
That'd be definitely a big help for the AMO Editors team. More
realistically, though, we just need to bring the queues back down to the
acceptable levels, which are 10 days for full nominations, 5 days for
updates and 3 days for preliminary reviews.

We're working on some other measures to reduce waiting times, like
hiring a full time editor who joined us last week, but it is unclear at
the moment if this will be sufficient.

- Jorge

Dao

unread,
Sep 21, 2011, 11:35:10 AM9/21/11
to
On 21.09.2011 17:21, Jorge Villalobos wrote:
>>>> Maybe we should hold back non-critical updates until the "Full Review
>>>> Updates"
>>>> queue is down to zero?
>>>
>>> Isn't the problem that for every update that rolls out (ie every 6
>>> weeks), a new mass of 'critical' ("Without this update, my add-on breaks
>>> in Firefox.next") add-on updates starts?
>>
>> I'm talking about non-critical Firefox updates.
>
> That'd be definitely a big help for the AMO Editors team. More
> realistically, though, we just need to bring the queues back down to the
> acceptable levels,

Is this actually more realistic? Can it happen within the next six days,
when Firefox 7 is due?

wgru...@gmail.com

unread,
Sep 21, 2011, 10:51:50 AM9/21/11
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org, rob...@ocallahan.org

Jeff Griffiths

unread,
Sep 21, 2011, 11:43:09 AM9/21/11
to dev-pl...@lists.mozilla.org
On 11-09-21 12:21 AM, Henri Sivonen wrote:
...
> What are the current time estimates for getting Silent Update and
> JetPack into Firefox? That is, for how long would we need to slow
> down?

There are no plans currently to get Jetpack into Firefox. For reasoning
on why, please see Myk's blog post addressing the issue:

http://mykzilla.blogspot.com/2011/08/why-add-on-sdk-doesnt-land-in-mozilla.html

If you have comments about the post, feel free to reply, email me
directly, or Myk, etc. We're happy to field questions on this.

cheers, Jeff

Benjamin Smedberg

unread,
Sep 21, 2011, 11:46:11 AM9/21/11
to Henri Sivonen, dev-pl...@lists.mozilla.org
On 9/21/2011 3:21 AM, Henri Sivonen wrote:
> On Wed, Sep 21, 2011 at 12:57 AM, Robert O'Callahan
> <rob...@ocallahan.org> wrote:
>> 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?
> What are the current time estimates for getting Silent Update and
> JetPack into Firefox? That is, for how long would we need to slow
> down?
What do you mean by "JetPack into Firefox"? The Jetpack SDK reached 1.0
status around the same time Firefox 4 shipped.

--BDS

wgru...@gmail.com

unread,
Sep 21, 2011, 11:54:21 AM9/21/11
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org, rob...@ocallahan.org
I forgot the link - my apologies.

http://www.conceivablytech.com/9419/business/browser-market-share-forecast-update-firefox-losses-accelerate

I have to admit, however that the confusion in this thread, with some pretty high ranking Mozillians advocating a shortening of the release cycle and others suggesting an extension is sending a very strange signal to the public. Sure, you guys are 'just' employees and you can always claim that these are your personal opinions and you are just talking, but, in such a forum, you will always represent Mozilla as well. You guys are quick to attack the press, but this case shows that you guys lack the very same diligence you complain about.

My personal opinion, for what it is worth, is that this discussion should not be held in public. I personally do not think that your shortened release cycle works, I do not think that it has provided any benefit, but just headaches for enterprise users and your market share declines faster than ever before (according to StatCounter). If you guys believe in the 6-week cycle, you need to finetune it, bring silent updates as fast as you can, provide stable versions for enterprise users until you have a better solution, and streamline your communication what Firefox will be and what not. Even if I have been following you guys for 7 years, I have no idea what to expect from Firefox and what it will look like one year from now.

What users will get from this discussion is that the 6-week cycle may change. It may be longer or shorter, or stay the same. It introduces uncertainty. I don't think that Mozilla needs discussions like this at this time. That's my personal opinion and not the opinion of ConceivablyTech.

Wolfgang

wgru...@gmail.com

unread,
Sep 21, 2011, 11:54:21 AM9/21/11
to dev-pl...@lists.mozilla.org, rob...@ocallahan.org

Ted Mielczarek

unread,
Sep 21, 2011, 12:04:02 PM9/21/11
to dev-pl...@lists.mozilla.org
On Wed, Sep 21, 2011 at 11:54 AM, <wgru...@gmail.com> wrote:
> Sure, you guys are 'just' employees and you can always claim that these are your personal opinions and you are just talking, but, in such a forum, you will always represent Mozilla as well. You guys are quick to attack the press, but this case shows that you guys lack the very same diligence you complain about.

> I don't think that Mozilla needs discussions like this at this time. That's my personal opinion and not the opinion of ConceivablyTech.

I see what you did there.

-Ted

Gijs Kruitbosch

unread,
Sep 21, 2011, 12:15:04 PM9/21/11
to
On 21/09/2011 17:54 PM, wgru...@gmail.com wrote:
> <snip>
> Sure, you guys are 'just' employees and you can always claim that these are your personal opinions and you are just talking, but, in such a forum, you will always represent Mozilla as well.
> <snip>

In what 'kind of forum', exactly, in your view? These are development/community
newsgroups/mailing lists, explicitly marked as such. A fine situation it would
be if developers could no longer discuss development matters on a newsgroup. The
fact that these newsgroups are public is to encourage participation from the
community, which is larger than just the employees. In fact, you provided a
great example yourself:

> I personally do not think that your shortened release cycle works, ...

So I'm rather confused why you are advocating they should move the discussion...

Gijs

Patrick Finch

unread,
Sep 21, 2011, 12:20:40 PM9/21/11
to mozilla.de...@googlegroups.com, wgru...@gmail.com, dev-pl...@lists.mozilla.org, rob...@ocallahan.org
Little off topic: but that article is speculating about Firefox's market
position for the whole month based on partial data for September, and
most of that data which has yet to pass StatCounter's own QA
(http://gs.statcounter.com/faq#update-frequency ).

and just looking at the last month's data in context
http://gs.statcounter.com/#os-ww-daily-20110101-20110921
(e.g. a spike in Vista usage?) shows that we might expect a revision of
it. Not advocating complacency, but I am not reading too much into that
piece.


Patrick

Christian Legnitto

unread,
Sep 21, 2011, 12:22:03 PM9/21/11
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org, rob...@ocallahan.org
To be clear:

* We are sticking with the 6 week cycle for the foreseeable future

Additionally:

1. We are an open project and discuss in the open. This is a *benefit* though it can cause confusion at times. We will *always* fall on the side of more open and are constantly worrying about not being open enough

2. There are different messages because...well...there are different opinions! Everyone has an opinion on what the future will bring and the right way to get Firefox where it needs to be. This is not a corporate product where we have to toe the company line. Everyone--employee or not--should feel free to speak up and discuss. Some valid discussion points can *only* be brought forward by volunteers (localization to name one in particular). Dev-planning is where we discuss in the open, any and everything planning and development related

3. We're working to clean up our communication channels so that reporters don't have to sift through the massive amount of Mozilla information and orient themselves in the various discussion contexts

4. For press, we have an amazing team (pr...@mozilla.com) that can field questions. They aren't your typical corporate press team. It goes from them *right to the expert* and back to you. Please use them, they are a valuable resource (I know your article isn't one that caused unnecessary churn)

5. I really, really don't want to get to the point where we have to use nuance and disclaimers for everything we discuss publicly. That's not productive, causes additional confusion, and will prevent us from acting boldy when we need to

We discuss and work in a fishbowl because we value transparency and openness. Please don't tap on the glass.

Thanks,
Christian

Jorge Villalobos

unread,
Sep 21, 2011, 12:33:06 PM9/21/11
to Dao
I got 2 ideas mixed up there. I think it would be more realistic to
bring down the update and preliminary review queues to the acceptable
levels. Full review nominations can wait (as usual :().

However, none of this is going to happen in the next 6 days. It would
take at least a few weeks *without* any major updates, which is clearly
not happening.

- Jorge

wgru...@gmail.com

unread,
Sep 21, 2011, 12:20:22 PM9/21/11
to
This is a publicly accessible forum, right?

Benoit Jacob

unread,
Sep 21, 2011, 12:45:50 PM9/21/11
to wgru...@gmail.com, dev-pl...@lists.mozilla.org
2011/9/21 <wgru...@gmail.com>:

> This is a publicly accessible forum, right?

Do you realize that Mozilla is an *open* project? As in, actually
open. Discussion happens in the open. That doesn't make it anything
more than that --- discussion.

Benoit

wgru...@gmail.com

unread,
Sep 21, 2011, 1:02:08 PM9/21/11
to wgru...@gmail.com, dev-pl...@lists.mozilla.org
I understand that completely. I actually care about you guys and believe that a competitive and strong Mozilla is important for all Internet users to keep a balance in the browser market and keep Microsoft and Google on their toes.

However, it is tough to watch you guys damaging you own opportunity with discussions like this. I would wish there was more responsibility on your side to anticipate the likely effect of a post like this, which is obviously not what you wanted and required lots of time on your side to correct. It is not the first time this has happened.

If I remember it correctly, one of your employees pitched the version number removal thingy as a given, but was later told that he may have interpreted something in the wrong way. We have had the enterprise user confusion that needed to be corrected. Now it is a shortened/lengthened/same release cycle time frame. Is it just me, or is there something broken? Is it the case that you guys actually want those false/misinterpreted messaged (which not only were distributed by the press by also by your own staff) to be in the open which you enjoy correcting afterwards? As a journalist, I like following your discussions, but as someone who cares about Firefox, I have to say it hurts to see how damaging these posts can be to Mozilla.

I also see it as a problem that if you guys are confronted with some constructive criticism, that there is lately a tendency to take this criticism personal and hit back with a big swing. It is not the Mozilla I know and I don't think you have the right approach here as well.

I am far from suggesting what you should change. I am not even saying that you should change. What I am saying is that you guys are constantly setting yourself up for false or misinterpreted messages. One day we may misinterpret you post, another day it will be a different blog. There is no end. It is up to you to make sure nothing is misinterpreted. That is, unless you want to continue dealing with those misinterpretations.

Again, this is my personal opinion.

Boris Zbarsky

unread,
Sep 21, 2011, 1:06:40 PM9/21/11
to
On 9/21/11 11:54 AM, wgru...@gmail.com wrote:
> I have to admit, however that the confusion in this thread, with some pretty high ranking Mozillians advocating a shortening of the release cycle and others suggesting an extension is sending a very strange signal to the public.

Uh... That's because there are different opinions on the way things
should go. You're reading an _internal_ discussion forum here. The
place where things that have NOT been decided are hashed out. There
will be suggestions made that will not result in any changes. There
will be differences of opinion. That's the whole point.

> Sure, you guys are 'just' employees and you can always claim that these are your personal opinions and you are just talking

We're not employees. We're project contributors. And this is the
mailing list/newsgroup that we discuss the planning for this project on.
Again, that means that there will be _discussion_. If you want a
location where decisions are announced, this is not it.

> but, in such a forum, you will always represent Mozilla as well.

In this forum, no one is representing anyone but themselves unless they
speak otherwise.

> You guys are quick to attack the press, but this case shows that you guys lack the very same diligence you complain about.

I have no idea what you're talking about here.

Again, you're writing articles about part of an internal project
discussion and making it sound like you're writing about an actual
policy change.

> My personal opinion, for what it is worth, is that this discussion should not be held in public.

How can we not hold it in public without excluding a large number of our
contributors? The whole POINT is that we hold our planning discussions
in public. Always. That way the community can participate as desired.

If you choose to read an internal discussion forum and be confused by
it, that's up to you, of course. If you then choose to publish articles
based on that it's also up to you, freedom of speech and all. But don't
pretend like people are purposefully trying to confuse you here and
you're somehow the victim.

> I have no idea what to expect from Firefox and what it will look like one year from now.

No one knows what Firefox will "look like" one year from now. One year
is a really long time.

> What users will get from this discussion is that the 6-week cycle may change.

Or may not. Everything in the world may change. Microsoft could open
source their office suite tomorrow. Apple could allow arbitrary
software installs on iOS.

Users who are just users and not interested in actual project planning
aren't reading this list anyway, and shouldn't be.

> It may be longer or shorter, or stay the same.

Yep. For the time being, it's staying the same until we have more data,
as Christian points out. Of course you didn't report that, did you?

> I don't think that Mozilla needs discussions like this at this time.

I don't think we should be muzzling _discussion_ at any point.

I do think people should avoid jumping to weird conclusions based on
said unmuzzled discussions.

-Boris

Boris Zbarsky

unread,
Sep 21, 2011, 1:14:46 PM9/21/11
to
On 9/21/11 1:02 PM, wgru...@gmail.com wrote:
> If I remember it correctly, one of your employees pitched the version number removal thingy as a given, but was later told that he may have interpreted something in the wrong way.

So.... In that case, the press decided to report on a bug report being
filed. Are you suggesting that people should never make mistakes? That
the bug database being closed? Something else?

Or maybe the press should ease off on the muckraking, perhaps?

> Is it just me, or is there something broken?

There is. The broken thing is people who read developer communication
channels, see someone ask "have we thought about X?" and write articles
saying "Mozilla is doing X!".

> Is it the case that you guys actually want those false/misinterpreted messaged (which not only were distributed by the press by also by your own staff) to be in the open which you enjoy correcting afterwards?

We want our communications to be in the open, period.

Sometimes that hurts, because people can in fact make mistakes. We
don't enjoy making mistakes.

But we do want to trust people to understand the difference between a
public discussion and a decision. Unfortunately, some people seem to
not get it....

> I also see it as a problem that if you guys are confronted with some constructive criticism

"You should hide all your developer discussions" is not constructive
criticism, sorry....

> I am far from suggesting what you should change. I am not even saying that you should change.

OK, good. :)

> What I am saying is that you guys are constantly setting yourself up for false or misinterpreted messages.

Yes, we realize that. We place some trust in people exercising
discretion and not jumping to conclusions. It's always a bit
disheartening when that trust is misplaced, but we're prefer to keep
trusting people to do the right thing.

> It is up to you to make sure nothing is misinterpreted.

That is a lower priority for us than open communications.

> That is, unless you want to continue dealing with those misinterpretations.

We don't _want_ to keep dealing with it, but we want to go to a closed
development model even less.

Here's an interesting question for you: why do other open source
projects with open developer communications (the Linux kernel, etc) not
get the same funhouse mirror effects going on? Oh, wait, they do. But
the press writes Linux kernel articles way more rarely than they write
Firefox articles.... and when they do write them they tend to be wrong.
That's just a fact of life: almost anything reported in the press will
be wrong. We deal with it.

-Boris

Mike Shaver

unread,
Sep 21, 2011, 1:22:12 PM9/21/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Wed, Sep 21, 2011 at 1:14 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Or maybe the press should ease off on the muckraking, perhaps?

I don't know that "muckraking" really elevates the discourse, but I
think that if you're writing news articles to help an external
audience learn things, then

- person says something that is surprising enough to be newsworthy
- check with person to see if you understood correctly, and that
they're stating fact not opinion or speculation
- write article with the warm glow of knowing you're on the right track

is better than

- person says something that is surprising enough to be newsworthy
- write article and headline that presents statement in most absolute
and extreme sense possible
- bathe in the clicks that the link-bait brought in

but I understand that the economics are against me, alas.

We have a *very* responsive press team at pr...@mozilla.com; I have
been called at 10PM at night to get an answer to something important
for a reporter on deadline. But then people might report on the basis
of facts rather than speculation and extrapolation, and reality is
usually more boring than carefully-written fiction.

Mike

Joshua Cranmer

unread,
Sep 21, 2011, 1:38:29 PM9/21/11
to
On 9/21/2011 12:02 PM, wgru...@gmail.com wrote:
> If I remember it correctly, one of your employees pitched the version number removal thingy as a given, but was later told that he may have interpreted something in the wrong way. We have had the enterprise user confusion that needed to be corrected. Now it is a shortened/lengthened/same release cycle time frame. Is it just me, or is there something broken? Is it the case that you guys actually want those false/misinterpreted messaged (which not only were distributed by the press by also by your own staff) to be in the open which you enjoy correcting afterwards? As a journalist, I like following your discussions, but as someone who cares about Firefox, I have to say it hurts to see how damaging these posts can be to Mozilla.
This thread strikes me as a clear indication of someone wanting to start
a discussion on whether or not it would make sense to speed up the
cycle--the title is a question, not a sentence after all, and the first
posts asked for requests for comments. It strikes me as an error of
judgement on the part of a journalist to have misinterpreted that as an
announcement of Mozilla speeding up its release process. I expect
journalists to be doing due diligence, and to report on official policy
of an organization (including Mozilla) by actually verifying that it is
official policy and not just an employee saying something.

The goal of Mozilla is to be as open as reasonably possible. This may
mean that it might be hard to distinguish between an employee speaking
as a participant in a discussion or an employee speaking on official
process, but, as has been previously pointed out, there are ways to
confirm official policy. Perhaps we ought to trumpet those more, but it
seems to me that actual technology journalists misreporting because of
not following through are journalists who are failing to live up to the
standards of journalism.

Disclaimer: I am not an employee of Mozilla, only an interested and
repeat contributor.

Wayne Mery

unread,
Sep 21, 2011, 1:41:08 PM9/21/11
to mozilla.de...@googlegroups.com, wgru...@gmail.com, dev-pl...@lists.mozilla.org
On 9/21/2011 1:02 PM, wgru...@gmail.com wrote:
> Is it just me,

perhaps not ONLY you in the entire universe, but yes...

The current thread bears no resemblance to the examples you cited. The
OP is a great mozillian but is not a project lead, and was pitching an
idea. period.

And if, as a journalist, you choose not contact sources or vet
information before reporting things as fact, one might think you do your
readers a disservice.

--
I speak for no one, except myself.

Wayne Mery

unread,
Sep 21, 2011, 1:41:08 PM9/21/11
to mozilla.de...@googlegroups.com, wgru...@gmail.com, dev-pl...@lists.mozilla.org

wgru...@gmail.com

unread,
Sep 21, 2011, 1:58:44 PM9/21/11