A five week release cycle?

[Josh Aas]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

> ...

> 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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

(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]

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]

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]

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]

[Jeff Griffiths]

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]

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]

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]

[Ted Mielczarek]

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]

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]

On 21/09/2011 17:54, wgru...@gmail.com wrote:
> I forgot the link - my apologies.
>
> http://www.conceivablytech.com/9419/business/browser-market-share-forecast-update-firefox-losses-accelerate

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]

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]

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]

This is a publicly accessible forum, right?

[Benoit Jacob]

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]

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]

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]

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]

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]

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]

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]

[wgru...@gmail.com]

as said, I am not defending the journalist who reported this issue with a headline of "Mozilla may shorten Firefox’s six-week release schedule to five weeks… or less" at http://www.extremetech.com/mobile/96737-mozilla-wants-to-shorten-firefoxs-six-week-release-schedule-to-five-weeks-or-less.

However, I am not quite sure what it takes to get someone at Mozilla to actually make an effort where the original article actually came from and why it was written.

[Mike Shaver]

On Wed, Sep 21, 2011 at 1:58 PM, <wgru...@gmail.com> wrote:
> However, I am not quite sure what it takes to get someone at Mozilla to actually make an effort where the original article actually came from and why it was written.

I don't quite understand that sentence (I think you a word), but are
you saying that Mozilla should go directly to the source and find out
the facts behind why a journalist wrote an article the way they
did...when that journalist didn't bother to get a comment from Mozilla
before writing their article?

Mike

[Boris Zbarsky]

On 9/21/11 1:58 PM, wgru...@gmail.com wrote:
> However, I am not quite sure what it takes to get someone at Mozilla to actually make an effort where the original article actually came from and why it was written.

So your real issue is that Robert misattributed the article at
http://www.extremetech.com/mobile/96737-mozilla-wants-to-shorten-firefoxs-six-week-release-schedule-to-five-weeks-or-less
to conceivablytech (which had a quite different and unrelated article at
http://www.conceivablytech.com/9419/business/browser-market-share-forecast-update-firefox-losses-accelerate
)?

Yes, that misattribution seems to have been incorrect.

-Boris

[wgru...@gmail.com]

Mike, Boris can help you out below. Beginning with Rob, several people here quoted and referred to the wrong source and did not make an effort to look at what the correct source was, even if they complained that (some) journalists are not diligent enough to look at the right sources.

That was quite an effort, and I think that the phrasing of your comment above is out of line. You make the very same mistake you complain about.

That was just one issue. What I attempted and apparently failed to do is to suggest that Mozilla's current communication model may have problems. I understand that your motivation not to change it, so let's not go into this again.

[Robert Kaiser]

wgru...@gmail.com schrieb:

> However, I am not quite sure what it takes to get someone at Mozilla to actually make an effort where the original article actually came from and why it was written.

I'm not quite sure where the times went where journalists were still
supposed to do some deeper investigations before reporting anything that
just popped into their mind when they saw some unconfirmed claim.

I guess journalism still has ways to go until it sports people who
understand how modern open communication works.

Mozilla is willing to help with that, but it requires trying to
understand the other side, not telling us that we can't speak our
personal opinion and asking questions about how to optimize processes in
a development planning forum.

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! :)

[Robert Kaiser]

Henri Sivonen schrieb:

> 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?

Last I heard, Jetpack doesn't _want_ to "be in Firefox" but stay its
own, separate thing. That said, Jetpack-powered add-ons already work
nicely with Firefox (desktop/mobile), Thunderbird and SeaMonkey in their
current release and dev versions.

[Ron Hunter]

On 9/21/2011 12:02 PM, wgru...@gmail.com wrote:

There is always a penalty with openness. Sometimes people don't
understand that something just being 'run up the flagpole to see if
anyone salutes it', and others get the idea it is a done deal. An
example is the idea for removing the version number from the About
Firefox Dialog box. It never happened, and never really WAS going to
happen, but caused a lot of response. In the end, too many people
pointed out good reasons NOT to do it. In any case, the discussion will
probably resurface in the future, and be discussed again, just as
shortening (or lengthening) the update cycle may be discussed.
People need to understand the discussion process, and not go too
ballistic if their favorite feature is being discussed.

[Robert O'Callahan]

On Thu, Sep 22, 2011 at 2:51 AM, <wgru...@gmail.com> wrote:

> 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're right. I mixed up extremetech and conceivablytech, sorry.

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]

[Robert O'Callahan]

On Thu, Sep 22, 2011 at 7:48 AM, <wgru...@gmail.com> wrote:

> Mike, Boris can help you out below. Beginning with Rob, several people here
> quoted and referred to the wrong source and did not make an effort to look
> at what the correct source was, even if they complained that (some)
> journalists are not diligent enough to look at the right sources.
>

Mea culpa, and I apologize again.

The difference is, of course, that I made a mistake in a message to a
project-discussion newsgroup and my mistake was not relevant to the point of
my message, whereas Extremetech made a mistake in a purported "news" article
to the world and their article was entirely based on that mistake.

It will make our lives difficult if every newsgroup and public mailing list
post is subject to the same scrutiny, fact-checking and correction regime as
articles on a news site. But still, a mistake's a mistake, so I apologize
again.

[David Mandelin]

On 9/20/2011 4:31 PM, Robert Strong wrote:
>
> 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

Good to hear. Is there an ETA on that stuff yet? I'm still kind of
concerned about non-silent update over the next few releases.

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

I think I heard about an enterprise working group being formed, but I
haven't heard anything about new tools or features.

Dave

[Robert Strong]

On 9/21/2011 4:16 PM, David Mandelin wrote:
> On 9/20/2011 4:31 PM, Robert Strong wrote:
>> 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
> Good to hear. Is there an ETA on that stuff yet? I'm still kind of
> concerned about non-silent update over the next few releases.

The current guesstimate is a month and a half for the majority of the
app update work.

Keep in mind that the main difference with rapid release is not how
often we release updates but how often we release updates that change
the major version. So, if an add-on is not compatible with the new
version by default we require the user to opt-in to the update which
shows ui and app update is already optimized to only do this when an
add-on that is compatible, enabled, not compatible with the new version,
and doesn't have an update available that will make it compatible with
the new version then the ui is shown. The add-ons compatible by default
effort is what will improve this specific scenario.

>>> 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.
> I think I heard about an enterprise working group being formed, but I
> haven't heard anything about new tools or features.

Probably because the focus has been on the "Proposal to Provide an
Extended Support Release of Firefox for Managed Deployments" and until
that is finalized I don't see much point in discussing additional items.
https://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/d7d3bc38366798fa#

The two features that have been brought up several times are MSI and
Group Policy Support both of which I think we should implement in some
fashion as long as it doesn't take resources away from other work.

> Dave
Robert

[David Mandelin]

On 9/21/2011 4:54 PM, Robert Strong wrote:

>
> On 9/21/2011 4:16 PM, David Mandelin wrote:
>> On 9/20/2011 4:31 PM, Robert Strong wrote:
>>> 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
>> Good to hear. Is there an ETA on that stuff yet? I'm still kind of
>> concerned about non-silent update over the next few releases.

> The current guesstimate is a month and a half for the majority of the
> app update work.

That sounds excellent. By the way, congrats on your new gig totally
fixing this and other platform stuff. (I replied here before checking
those emails, doh!)

>
> Keep in mind that the main difference with rapid release is not how
> often we release updates but how often we release updates that change
> the major version. So, if an add-on is not compatible with the new
> version by default we require the user to opt-in to the update which
> shows ui and app update is already optimized to only do this when an
> add-on that is compatible, enabled, not compatible with the new
> version, and doesn't have an update available that will make it
> compatible with the new version then the ui is shown. The add-ons
> compatible by default effort is what will improve this specific scenario.

Good point. The update dialogs on startup are kind of annoying, but from
my unscientific surveys of the blogs, it sounds like addon compat is the
only thing that really bothers people. I don't know about the add-ons
compatible by default effort, but it sounds like just the thing.

>>>> 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.
>> I think I heard about an enterprise working group being formed, but I
>> haven't heard anything about new tools or features.

> Probably because the focus has been on the "Proposal to Provide an
> Extended Support Release of Firefox for Managed Deployments" and until
> that is finalized I don't see much point in discussing additional items.
> https://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/d7d3bc38366798fa#
>

Doh^2, I also saw that one just after posting the above. It looks good.

> The two features that have been brought up several times are MSI and
> Group Policy Support both of which I think we should implement in some
> fashion as long as it doesn't take resources away from other work.

At this point, it seems we need both of those in order to be
competitive. I don't understand "as long as it doesn't take away from
other work"--there's always an opportunity cost, so I don't see how that
condition can be satisfied. I also don't know enough to offer an
informed opinion on its relative importance, but my uninformed opinion
is that the ESR proposal is more important, so MSI and Group Policy are
not that urgent; but on the other hand there is a prime opportunity to
show we care by doing them right away.

Dave

[Christian Legnitto]

On Sep 21, 2011, at 5:05 PM, David Mandelin wrote:

> On 9/21/2011 4:54 PM, Robert Strong wrote:

>>
>> On 9/21/2011 4:16 PM, David Mandelin wrote:
>>> On 9/20/2011 4:31 PM, Robert Strong wrote:
>>>> 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
>>> Good to hear. Is there an ETA on that stuff yet? I'm still kind of
>>> concerned about non-silent update over the next few releases.

>> The current guesstimate is a month and a half for the majority of the
>> app update work.
>
> That sounds excellent. By the way, congrats on your new gig totally
> fixing this and other platform stuff. (I replied here before checking
> those emails, doh!)
>
>>
>> Keep in mind that the main difference with rapid release is not how
>> often we release updates but how often we release updates that change
>> the major version. So, if an add-on is not compatible with the new
>> version by default we require the user to opt-in to the update which
>> shows ui and app update is already optimized to only do this when an
>> add-on that is compatible, enabled, not compatible with the new
>> version, and doesn't have an update available that will make it
>> compatible with the new version then the ui is shown. The add-ons
>> compatible by default effort is what will improve this specific scenario.
>
> Good point. The update dialogs on startup are kind of annoying, but from
> my unscientific surveys of the blogs, it sounds like addon compat is the
> only thing that really bothers people. I don't know about the add-ons
> compatible by default effort, but it sounds like just the thing.

I had talked to Rob about the progress dialog earlier and he said the knobs are already there we just need to turn them to zero:

https://bugzilla.mozilla.org/show_bug.cgi?id=685614

Didn't make it for Firefox 7 but I intend to get it for 8 if we can.

Add-on compatible by default:

https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible

Led by fligtar, not it only applies to non-binary add-ons.

This further reinforces my feeling we to need to do a better job communicating.

Thanks,
Christian

[Robert Strong]

On 9/21/2011 5:05 PM, David Mandelin wrote:
> On 9/21/2011 4:54 PM, Robert Strong wrote:

>> On 9/21/2011 4:16 PM, David Mandelin wrote:
>>> On 9/20/2011 4:31 PM, Robert Strong wrote:
>>>> 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
>>> Good to hear. Is there an ETA on that stuff yet? I'm still kind of
>>> concerned about non-silent update over the next few releases.

>> The current guesstimate is a month and a half for the majority of the
>> app update work.
> That sounds excellent. By the way, congrats on your new gig totally
> fixing this and other platform stuff. (I replied here before checking
> those emails, doh!)

Thanks!

>> Keep in mind that the main difference with rapid release is not how
>> often we release updates but how often we release updates that change
>> the major version. So, if an add-on is not compatible with the new
>> version by default we require the user to opt-in to the update which
>> shows ui and app update is already optimized to only do this when an
>> add-on that is compatible, enabled, not compatible with the new
>> version, and doesn't have an update available that will make it
>> compatible with the new version then the ui is shown. The add-ons
>> compatible by default effort is what will improve this specific scenario.
> Good point. The update dialogs on startup are kind of annoying, but from
> my unscientific surveys of the blogs, it sounds like addon compat is the
> only thing that really bothers people. I don't know about the add-ons
> compatible by default effort, but it sounds like just the thing.
>

>>>>> 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.
>>> I think I heard about an enterprise working group being formed, but I
>>> haven't heard anything about new tools or features.

>> Probably because the focus has been on the "Proposal to Provide an
>> Extended Support Release of Firefox for Managed Deployments" and until
>> that is finalized I don't see much point in discussing additional items.
>> https://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/d7d3bc38366798fa#
>>
> Doh^2, I also saw that one just after posting the above. It looks good.
>
>> The two features that have been brought up several times are MSI and
>> Group Policy Support both of which I think we should implement in some
>> fashion as long as it doesn't take resources away from other work.
> At this point, it seems we need both of those in order to be
> competitive. I don't understand "as long as it doesn't take away from
> other work"--there's always an opportunity cost, so I don't see how that
> condition can be satisfied. I also don't know enough to offer an
> informed opinion on its relative importance, but my uninformed opinion
> is that the ESR proposal is more important, so MSI and Group Policy are
> not that urgent; but on the other hand there is a prime opportunity to
> show we care by doing them right away.

I was purposely vague with "take resources away from other work" mainly
because we don't have resources or priority assigned for this work. Some
of the ways this could be accomplished without taking resources away
from other work are:
1. make the work a priority for Mozilla.
2. contributors (most of the current MSI work was done during khuey's
"free" time and the current installer command line options was done on
weekends during my "free" time).
3. hire a contractor to do it.
4. resources currently not assigned that want to do this work.
5. other options?

I've been an advocate of making our deployment story better since I
started at Mozilla but I very much want Mozilla to commit to making it
better by allocating resources to the effort.

> Dave
Robert

--
Cheers,
Robert Strong

[David Mandelin]

This sounds like a good project for a contractor. I also think it could
work out really well if some enterprise users wanted to contribute these
features (with assistance from someone here)--they would know exactly
what's needed.

Dave

[John Hopkins]

>>>>>> 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.
>>>> I think I heard about an enterprise working group being formed, but I
>>>> haven't heard anything about new tools or features.

>>> Probably because the focus has been on the "Proposal to Provide an
>>> Extended Support Release of Firefox for Managed Deployments" and until
>>> that is finalized I don't see much point in discussing additional items.
>>> https://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/d7d3bc38366798fa#
>>>
>>>
>> Doh^2, I also saw that one just after posting the above. It looks good.
>>

I've been following some of the MSI-related bug entries.

That left me wondering: What would we consider to be a "minimum viable
solution" for enterprise deployments? To my mind, it would be:

- group policy support (bug 267888)
- a non-graphical MSI installer

What might be considered optional?

- graphical installer
- side-by-side installs (eg. release + beta)

Some clarity on this would be very helpful for planning purposes.

John

[Benjamin Smedberg]

On 9/21/2011 8:44 PM, John Hopkins wrote:
>
> That left me wondering: What would we consider to be a "minimum viable
> solution" for enterprise deployments? To my mind, it would be:
>
> - group policy support (bug 267888)

That is potentially a huge bucket. It really depends on what kinds of
policies various enterprises want. There is almost an infinite variety,
and some are going to be much more difficult than others.

There's no particular reason why we can't do individual policies one at
a time, and we should. But anything like this is going to have to be
accompanied by a fair number of automated tests, which is going to be
the hard part of the project.

--BDS

[Robert Strong]

Let's change the subject so the thread isn't hijacked.

On 9/21/2011 5:44 PM, John Hopkins 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 though there haven't been as of yet as
>>>>>> far
>>>>>> as I know.
>>>>> I think I heard about an enterprise working group being formed, but I
>>>>> haven't heard anything about new tools or features.

> That left me wondering: What would we consider to be a "minimum viable
> solution" for enterprise deployments? To my mind, it would be:
>
> - group policy support (bug 267888)

> - a non-graphical MSI installer
>
> What might be considered optional?
>
> - graphical installer
> - side-by-side installs (eg. release + beta)
>
> Some clarity on this would be very helpful for planning purposes.

In some cases MSI will be a huge improvement over their current
processes since we could easily provide a SCUP file to ease their
deployments.
http://technet.microsoft.com/en-us/systemcenter/bb741049.aspx

One thing I am adamant about is that we have to be able to update MSI
installations ourselves so if user's start using MSI's we can keep them
up to date and doing so using anything other than MSP's (
http://msdn.microsoft.com/en-us/library/aa370578.aspx ) is really not a
reasonable option as I see it.

> John
Robert

[Henri Sivonen]

On Wed, Sep 21, 2011 at 6:43 PM, Jeff Griffiths <jgrif...@mozilla.com> wrote:
> 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

This explains why keeping the SDK separate from Firefox is convenient
for the developers of the SDK. It doesn't explain how keeping it
separate is better for extension authors. How is it better for
extension authors?

On Wed, Sep 21, 2011 at 6:46 PM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
> What do you mean by "JetPack into Firefox"? The Jetpack SDK reached 1.0
> status around the same time Firefox 4 shipped.

As I understand it, there are three main pieces:
1) The ever-changing internal APIs of Firefox.
2) A stable extension API that is implemented on top of the internal
APIs and hides the internal APIs.
3) The extension author-provided code that uses the stable API.

My understanding is that currently pieces #2 and #3 are packaged in a
extension xpi and the extension xpi needs repacking when #1 and,
consequently, #2 change. I gather this is a pain for extensions not
hosted on AMO, since the automatic repacking functionality is part of
AMO.

By "JetPack into Firefox" I mean shipping both #1 and #2 as part of
Firefox so that extension xpis would only need to contain piece #3 and
wouldn't need repacking when #1 changes. That is, I mean having a
stable JS-based extension API as part of the browser itself as in
Chrome, Safari and Opera so that there's no need to repack extensions
when the browser's internals are changed.

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

[Henri Sivonen]

On Thu, Sep 22, 2011 at 2:54 AM, Robert Strong <rst...@mozilla.com> wrote:
> So, if an add-on is not compatible with the new version by default
> we require the user to opt-in to the update

If the user has an incompatible add-on at the time the new version of
Firefox becomes available and the user doesn't opt-in, how will the
system recover from the opt-out and keep the user secure going
forward? Will the update happen automatically when a compatible
version of the add-on becomes available? If the add-on doesn't become
compatible in a few weeks, will there be something to remind the user
that (s)he's running an browser with disclosed vulnerabilities thanks
to an add-on holding updates back?

[Robert Strong]

On 9/21/2011 10:23 PM, Henri Sivonen wrote:
> On Thu, Sep 22, 2011 at 2:54 AM, Robert Strong<rst...@mozilla.com> wrote:
>> So, if an add-on is not compatible with the new version by default
>> we require the user to opt-in to the update
> If the user has an incompatible add-on at the time the new version of
> Firefox becomes available and the user doesn't opt-in, how will the
> system recover from the opt-out and keep the user secure going
> forward?

It checks every 24 hours.
We are looking at tuning this behavior especially for the incompatible
add-on case in
https://wiki.mozilla.org/Silent_Update_not_now_prompt

> Will the update happen automatically when a compatible
> version of the add-on becomes available?

Yes

> If the add-on doesn't become
> compatible in a few weeks, will there be something to remind the user
> that (s)he's running an browser with disclosed vulnerabilities thanks
> to an add-on holding updates back?

Yes per the check happening every 24 hours

Robert

[mirc...@gmail.com]

five week cycle SUPERB!

[dfi...@web.de]

Hello

I would like to have a 4 week cycle and the version number like AMD Catalyst drivers (year.month).

For example:
Firefox v11.10 = 2011 October
Firefox v12.01 = 2012 January

So the version number is not growing so fast like it is now.

Thanks

[Philip Chee]

On Wed, 21 Sep 2011 14:22:07 +0200, 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?

But that will be "never" given the ever accelerating rates of submissions.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Dao]

On 22.09.2011 13:00, Philip Chee wrote:
> On Wed, 21 Sep 2011 14:22:07 +0200, 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?
>
> But that will be "never" given the ever accelerating rates of submissions.

No. If the number of pending reviews is still growing, it means we need
more people spending more time on it.

[Steve Wendt]

On 9/21/2011 10:08 PM, Henri Sivonen wrote:

> As I understand it, there are three main pieces:
> 1) The ever-changing internal APIs of Firefox.
> 2) A stable extension API that is implemented on top of the internal
> APIs and hides the internal APIs.
> 3) The extension author-provided code that uses the stable API.
>
> My understanding is that currently pieces #2 and #3 are packaged in a
> extension xpi and the extension xpi needs repacking when #1 and,
> consequently, #2 change. I gather this is a pain for extensions not
> hosted on AMO, since the automatic repacking functionality is part of
> AMO.
>
> By "JetPack into Firefox" I mean shipping both #1 and #2 as part of
> Firefox so that extension xpis would only need to contain piece #3 and
> wouldn't need repacking when #1 changes. That is, I mean having a
> stable JS-based extension API as part of the browser itself as in
> Chrome, Safari and Opera so that there's no need to repack extensions
> when the browser's internals are changed.

Perhaps the best of both worlds could be achieved by having some
mechanism for choosing between the JetPack in the browser, and the
JetPack in the extension (whichever has the higher version), assuming
they are compatible. If they are not compatible, then the extension
needs to be updated anyway?

[Josh Aas]

The intent was to start a discussion so that I could better understand people's concerns and the challenges we would face. Mission accomplished, though I didn't foresee the degree to which my post would be misinterpreted.

[fedora....@gmail.com]

How to kill Firefox :
- kill addons
How to kill addons :
- short cycles

Firefox is dead, long live to Chrome... :(

[Alex Limi]

On Tue, Sep 27, 2011 at 11:41 AM, <fedora....@gmail.com> wrote:

> How to kill Firefox :
> - kill addons
> How to kill addons :
> - short cycles
>

http://blog.fligtar.com/2011/09/26/add-on-compatibility-progress-plans/ —
add-ons should be compatible by default soon.

--
Alex Limi · Firefox UX Team · +limi <http://profiles.google.com/limi> ·
@limi <http://twitter.com/limi/> · limi.net

[fedora....@gmail.com]

This comes way too late. I personally have lost 12 very important addons since firefox 4. It's more than the half.
I have now more Addons on Chrome and I know they will be compatibles with the next release. Why should people stay with firefox when it's sure that a lot of addons will die every five or six weeks?

[Jean-Marc Desperrier]

fedora....@gmail.com wrote:
> This comes way too late. I personally have lost 12 very important
> addons since firefox 4. It's more than the half.

Do you have a list ?

Maybe installing an update could offer an option to report to Mozilla
which add-on have been disabled, in order to get a better view of how
many users are impaired by disabled add-on when switching version ?

The advantage of doing it that way is that it gives a much better
visibility on how many of those add-ons are not coming from AMO and not
covered by the current compatibility testing.

[Ron Hunter]

On 9/28/2011 4:11 AM, fedora....@gmail.com wrote:
> This comes way too late. I personally have lost 12 very important addons since firefox 4. It's more than the half.
> I have now more Addons on Chrome and I know they will be compatibles with the next release. Why should people stay with firefox when it's sure that a lot of addons will die every five or six weeks?

If you are willing to accept the same limitations on your extensions as
are required by Chrome, FF could do that. But if you want flexibility,
power, and customization, FF is the ONLY game in town.

[kaze]

On Sep 29, 1:06 am, Ron Hunter <rphun...@charter.net> wrote:

Why can't Firefox major updates be the ones that *actually* break
compatibility (new APIs) while the other updates are set off as minor
updates with improvements and enhancements. That way, the already well-
laid out 'Major Update' dialog can be used only when really needed.

It's not the number that makes firefox what it is, and with new
release cycle, features given to users at a faster pace.

PS: I personally hate Google Chrome's auto silent update and I hope
that mozilla's solution will NOT involve a persistent process checking
for updates (firefox is already constantly running on my system).

[Christian Legnitto]

On Sep 29, 2011, at 3:07 PM, kaze wrote:

> On Sep 29, 1:06 am, Ron Hunter <rphun...@charter.net> wrote:
>> On 9/28/2011 4:11 AM, fedora.addic...@gmail.com wrote:
>>
>>> This comes way too late. I personally have lost 12 very important addons since firefox 4. It's more than the half.
>>> I have now more Addons on Chrome and I know they will be compatibles with the next release. Why should people stay with firefox when it's sure that a lot of addons will die every five or six weeks?
>>
>> If you are willing to accept the same limitations on your extensions as
>> are required by Chrome, FF could do that. But if you want flexibility,
>> power, and customization, FF is the ONLY game in town.
>
> Why can't Firefox major updates be the ones that *actually* break
> compatibility (new APIs) while the other updates are set off as minor
> updates with improvements and enhancements. That way, the already well-
> laid out 'Major Update' dialog can be used only when really needed.

Each version has the potential to have incompatible changes (and with binary add-ons they are guaranteed). There is no longer a distinction between "change everything" updates (major) and "changes nothing updates" (minor). Each of our updates are now "changes something" (delivered as minor updates but numbered as major updates).

If we called them 8.1 or 8.0.1 or whatever we'd get just as many complaints that we couldn't change X or Y in a minor update and we are breaking users. We could then say "fine, we won't change X or Y in a minor update" which would slow Firefox development and put us right back where we started (and we'd likely miss tracking something and change it anyway).

> It's not the number that makes firefox what it is, and with new
> release cycle, features given to users at a faster pace.

Yep, we feel the same way, which is one of the reasons why we picked the simplest possible numbering scheme...just add one. To see the *public* discussions and decisions about version numbers, please search this newsgroup.

> PS: I personally hate Google Chrome's auto silent update and I hope
> that mozilla's solution will NOT involve a persistent process checking
> for updates (firefox is already constantly running on my system)

It appears from the windows update service bug there will be a way to fall back to current behavior. Follow along yourself, but please no "me too"/opinion comments:

https://bugzilla.mozilla.org/show_bug.cgi?id=481815

Thanks,
Christian