Apology from Jono about that blog post

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Apology from Jono about that blog post

Jono Xia-2
Everybody: I'm sorry. I'm REALLY REALLY sorry.

I never meant to cause harm to the Mozilla mission. I never imagined the
post I wrote (http://evilbrainjono.net/blog?permalink=1094) would go
viral or get the kind of reaction it has gotten.

When I wrote the post, I hoped it would be constructive criticism, but
it seems to have turned into the other kind. Of course, the internet
being what it is, I was naiive to think what I wrote would stay confined
to my blog audience. I wish I could go back in time and undo posting it,
or friends-lock it, or at least give it a title that was less likely to
be turned into flame-bait. I wish I had chosen my words more carefully.

I've learned a lot in the last few days about the uncontrollable beast
that is internet fame.  I realized that most of the sites re-blogging it
haven't even read what I wrote; they didn't bother to get my name right
or my employment status or former job title. There's nothing I wrote
that hasn't been said by lots of people before, inside and outside
Mozilla; the only reason this got picked up by so many gossip websites
was because editors thought  "Firefox dev Jono DiCarlo says Firefox
suxx" would make irresistable link-bait, facts be damned. Never mind
that I'm not (never was) a Firefox dev, that my name isn't DiCarlo, and
I don't think Firefox suxx!

The main point I wanted to make, which got lost in all the noise, is
about the difference between the developer perspective and the user
perspective, and about how developers (everywhere, not just at Mozilla)
should give more weight to the pain that updates inflict on users before
pushing them out. I stand by that point. I just wish I had made it more
clearly and less angrily.

I also believe Mozilla has been doing the right thing and gradually
correcting most of the mistakes of the rapid release process, and that
since Firefox 13 or so, updates have actually been pretty good -- as I
said at the end of my post, and in my follow-up post. Unfortunately I
didn't emphasize that part of my message enough.

The last few days have been agonizing. When I saw that Mozilla had to
write a press release to control the PR damage from my post, I was
heartbroken. Believe me, if I ever wanted one of my posts to go viral
and get read widely, it wouldn't have been that one.

Please share this message with anyone in Mozilla who has been hurt by my
actions.

TL;DR - I didn't mean for this to happen, I'm just bad at the internet.
Sorry, everyone.

--Jono
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

David Bruant-5
Le 13/07/2012 16:20, Jono Xia a Γ©crit :
> Everybody: I'm sorry. I'm REALLY REALLY sorry.
I wish to express that you have nothing to appologize for.
You wrote a blog post. The blog post was a personal statement. Nothing
was offensive is any fashion to anyone. Maybe there were some
hyperboles, maybe some inacuracies, maybe some statements were of the
realm of feelings rather than facts. That's the definition of a
blogpost, right?

Moving forward, it's interesting to see the reactions it has triggered.
There is a lot to be learnt from the reactions and a lot to be learnt
from how Firefox is being perceived.
I see very positively that following your blogpost, we get to read how
people percieve Firefox and that Mozilla gets an occasion to answer in
an official Press Release about some concerns that were true but aren't
any longer since recently (namely silent updates and compatible add-ons
by default).

I'm glad your blogpost made such waves if the end result is a broader
highlight of some recent Firefox improvements.

David
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Robert Kaiser
In reply to this post by Jono Xia-2
Jono Xia schrieb:

> I've learned a lot in the last few days about the uncontrollable beast
> that is internet fame.  I realized that most of the sites re-blogging it
> haven't even read what I wrote; they didn't bother to get my name right
> or my employment status or former job title. There's nothing I wrote
> that hasn't been said by lots of people before, inside and outside
> Mozilla; the only reason this got picked up by so many gossip websites
> was because editors thought  "Firefox dev Jono DiCarlo says Firefox
> suxx" would make irresistable link-bait, facts be damned. Never mind
> that I'm not (never was) a Firefox dev, that my name isn't DiCarlo, and
> I don't think Firefox suxx!

Yes, that's what "journalism" seems to have become for many: take a few
words and make up new "facts" around them that make an interesting
story. Do no care if any of it is true.
Unfortunately, this time the few words were from you and the story they
made out of them was hurting our image. But the next time, it'll be
others. Unfortunately, it almost always is about hurting some project,
often really good ones. In the end, bad news sell better than good news,
I guess. :(

> I also believe Mozilla has been doing the right thing and gradually
> correcting most of the mistakes of the rapid release process, and that
> since Firefox 13 or so, updates have actually been pretty good -- as I
> said at the end of my post, and in my follow-up post. Unfortunately I
> didn't emphasize that part of my message enough.

The last paragraph of you post just wasn't interesting enough for the
press, as it wasn't a story. "Mozillian says Firefox sucks" was, even
though it was a clear mis-interpretation.

(That said, "we suck" was a running gag on IRC in Netscape times and
used for all cases where our code ended up doing unexpected things. And
we, even me as a volunteer contributor, had a lot of fun with that.)

> TL;DR - I didn't mean for this to happen, I'm just bad at the internet.

Now, there I don't believe you. You've never in the last years been "bad
at the internet". You just miscalculated its effect. Happens to all of
us (or at least to many), in different sizes. ;-)

You for sure continue to be welcome as a Mozillian, and I hope to see
you around in some form in the future!

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

PhillipJones
In reply to this post by Jono Xia-2
Jono Xia wrote:

> Everybody: I'm sorry. I'm REALLY REALLY sorry.
>
> I never meant to cause harm to the Mozilla mission. I never imagined the
> post I wrote (http://evilbrainjono.net/blog?permalink=1094) would go
> viral or get the kind of reaction it has gotten.
>
> When I wrote the post, I hoped it would be constructive criticism, but
> it seems to have turned into the other kind. Of course, the internet
> being what it is, I was naiive to think what I wrote would stay confined
> to my blog audience. I wish I could go back in time and undo posting it,
> or friends-lock it, or at least give it a title that was less likely to
> be turned into flame-bait. I wish I had chosen my words more carefully.
>
> I've learned a lot in the last few days about the uncontrollable beast
> that is internet fame. I realized that most of the sites re-blogging it
> haven't even read what I wrote; they didn't bother to get my name right
> or my employment status or former job title. There's nothing I wrote
> that hasn't been said by lots of people before, inside and outside
> Mozilla; the only reason this got picked up by so many gossip websites
> was because editors thought "Firefox dev Jono DiCarlo says Firefox suxx"
> would make irresistable link-bait, facts be damned. Never mind that I'm
> not (never was) a Firefox dev, that my name isn't DiCarlo, and I don't
> think Firefox suxx!
>
> The main point I wanted to make, which got lost in all the noise, is
> about the difference between the developer perspective and the user
> perspective, and about how developers (everywhere, not just at Mozilla)
> should give more weight to the pain that updates inflict on users before
> pushing them out. I stand by that point. I just wish I had made it more
> clearly and less angrily.
>
> I also believe Mozilla has been doing the right thing and gradually
> correcting most of the mistakes of the rapid release process, and that
> since Firefox 13 or so, updates have actually been pretty good -- as I
> said at the end of my post, and in my follow-up post. Unfortunately I
> didn't emphasize that part of my message enough.
>
> The last few days have been agonizing. When I saw that Mozilla had to
> write a press release to control the PR damage from my post, I was
> heartbroken. Believe me, if I ever wanted one of my posts to go viral
> and get read widely, it wouldn't have been that one.
>
> Please share this message with anyone in Mozilla who has been hurt by my
> actions.
>
> TL;DR - I didn't mean for this to happen, I'm just bad at the internet.
> Sorry, everyone.
>
> --Jono

Why do you want to apologize for speaking the truth.  The big wheels at
Mozilla will never change. Unless people like you who have some
influence and clout tell the truth. The don't listen to their customers
and big business that had been using FireFox are leaving in droves to
other browsers. Upgrades should only come once every three to six
months. Would give people time enough to get use to and get comfortable
with the new features.
This putting out updates every other day is maddness.

The object is not to emulate Chrome. Chrome is a piece a junk and I hate
using it.  a web browser should what its supposed to. But the object is
not to look so much like a another brands that users get the two confused.
However unless people like you speak up and speak you mind, it will fall
on deaf ears.

--
Phillip M. Jones, C.E.T.        "If it's Fixed, Don't Break it"
http://www.phillipmjones.net        mailto:[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Asa Dotzler
On 7/13/2012 4:02 PM, PhillipJones wrote:
 > The object is not to emulate Chrome.

You are correct. That is not the object and that has never been a goal
put forward by anyone involved with Firefox product direction.

- A

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Philip Chee
On Fri, 13 Jul 2012 16:39:20 -0700, Asa Dotzler wrote:
> On 7/13/2012 4:02 PM, PhillipJones wrote:
>  > The object is not to emulate Chrome.
>
> You are correct. That is not the object and that has never been a goal
> put forward by anyone involved with Firefox product direction.

It's true that that has never been an explicit goal, but you can't deny
that there has been a lot of chrome envy informing decisions on the
direction that Firefox should go.

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Henri Sivonen
On Sat, Jul 14, 2012 at 6:56 AM, Philip Chee <[hidden email]> wrote:

> On Fri, 13 Jul 2012 16:39:20 -0700, Asa Dotzler wrote:
>> On 7/13/2012 4:02 PM, PhillipJones wrote:
>>  > The object is not to emulate Chrome.
>>
>> You are correct. That is not the object and that has never been a goal
>> put forward by anyone involved with Firefox product direction.
>
> It's true that that has never been an explicit goal, but you can't deny
> that there has been a lot of chrome envy informing decisions on the
> direction that Firefox should go.

Actually, I think the biggest thing that went wrong with Rapid Release
was the failure to imitate Chrome even more *up front*. Chrome had a
superb silent update system from day one--even before they started
releasing every six weeks. And when Chrome introduced extensions, the
API did not expose a random parts of engine internals. In contrast,
the Firefox Silent Update program was still in the definition phase
long after we had already started shipping rapidly and the stable
JetPack API lived on the extension side rather than on the Firefox
side when rapid releases started rolling out (dunno where the stable
API lives now).

Even though update silence has now been fixed on Windows (but AFAIK
not fully on Mac) and in that sense this is water under the bridge
(although the word of mouth does not appear to have picked up the fact
that on Windows it's water under the bridge), in order to do better in
the future, I think it would be worthwhile to consider what kind of
cognitive biases led to such a focus on the upsides (which are
significant) of rapid release to such a degree that rapid releases
were able to start reaching end users without the critical
prerequisites in place.

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

L. David Baron
On Saturday 2012-07-14 15:30 +0300, Henri Sivonen wrote:
> Actually, I think the biggest thing that went wrong with Rapid Release
> was the failure to imitate Chrome even more *up front*. Chrome had a
> superb silent update system from day one--even before they started
> releasing every six weeks. And when Chrome introduced extensions, the

But even before rapid release, we were shipping updates to our users
every six weeks (with some requiring followup updates to fix
regressions); it's just most of those updates were security updates.
(Though I guess we didn't stick to the six week cadence as
precisely.  I think it was still the goal.)

But we were still notifying our users of updates just as often.

So I agree that building a less intrusive update system is a good
thing, but I don't see how it's related to rapid release.

-David

--
π„ž   L. David Baron                         http://dbaron.org/   π„‚
𝄒   Mozilla                           http://www.mozilla.org/   π„‚
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Chris Hofmann-3
On 7/14/12 7:46 AM, L. David Baron wrote:

> On Saturday 2012-07-14 15:30 +0300, Henri Sivonen wrote:
>> Actually, I think the biggest thing that went wrong with Rapid Release
>> was the failure to imitate Chrome even more *up front*. Chrome had a
>> superb silent update system from day one--even before they started
>> releasing every six weeks. And when Chrome introduced extensions, the
> But even before rapid release, we were shipping updates to our users
> every six weeks (with some requiring followup updates to fix
> regressions); it's just most of those updates were security updates.
> (Though I guess we didn't stick to the six week cadence as
> precisely.  I think it was still the goal.)
>
> But we were still notifying our users of updates just as often.
>
> So I agree that building a less intrusive update system is a good
> thing, but I don't see how it's related to rapid release.
>
> -David
>
Yes, we're shipping the same number of releases per year, but
one of the problems is that under the previous release system
we were shipping about 1 or 2 releases per year with significant
regressions that resulted in the need to follow up with a quick
replacement release.

Nearly every one of the releases in the last 15 months have required
a quick X.01 follow up release for a variety of different reasons;
but the net effect is that we broke a significant number of users
  in significant ways when the bits were put on the wire.

Part of this is that we haven't hit the targets for beta and aurora
populations which would allow us to surface regressions faster
and get them fixed before shipping to the larger population.
Work is underway to help fix that, but still not to our original target
levels.

In general, users don't like to be annoyed.   A small part of the
annoyance comes from frequent update dialogs, but a larger
part of the annoyance comes from breaking addons, breaking
websites, breaking plugins, and introducing crash problems.
Until we find ways to get those things under control we won't
solve this problem.

Spreading the releases out on a longer cycle, of say 1 per quarter,
would result in breaking users about 50% less.  That's the fastest,
easiest, and biggest immediate impact thing to try if we are trying
to design a release system that works for users.

-chofmann

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Philip Chee
In reply to this post by Henri Sivonen
On Sat, 14 Jul 2012 07:46:17 -0700, L. David Baron wrote:

> On Saturday 2012-07-14 15:30 +0300, Henri Sivonen wrote:
>> Actually, I think the biggest thing that went wrong with Rapid Release
>> was the failure to imitate Chrome even more *up front*. Chrome had a
>> superb silent update system from day one--even before they started
>> releasing every six weeks. And when Chrome introduced extensions, the
>
> But even before rapid release, we were shipping updates to our users
> every six weeks (with some requiring followup updates to fix
> regressions); it's just most of those updates were security updates.
> (Though I guess we didn't stick to the six week cadence as
> precisely.  I think it was still the goal.)
>
> But we were still notifying our users of updates just as often.
>
> So I agree that building a less intrusive update system is a good
> thing, but I don't see how it's related to rapid release.
>
> -David

Yes but those updates were security updates which meant:
1. No change in UI (try retraining your muscle memory every six weeks if
the pedal positions in your car kept changing as often).

One small change in UI isn't fatal. But it's the fatal drip drip drip of
small UI changes every six weeks. Eventually this pushes many users over
the edge.

2. No (or almost none) addons broken.

Many users don't use addons at all. But for those that do, there are
people who abslouely depend on certain extensions for their
productivity. Breaking those extensions causes a lot of stress in those
people. I know users who have done a personal calculus and decided that
uninterrupted productivity is more important than security updates and
have resolved to take the calculated risk of avoiding updates until
absolutely necessary.

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Henri Sivonen
In reply to this post by L. David Baron
On Sat, Jul 14, 2012 at 5:46 PM, L. David Baron <[hidden email]> wrote:
> But even before rapid release, we were shipping updates to our users
> every six weeks (with some requiring followup updates to fix
> regressions); it's just most of those updates were security updates.
> (Though I guess we didn't stick to the six week cadence as
> precisely.  I think it was still the goal.)
>
> But we were still notifying our users of updates just as often.

The old point releases virtually never drew user attention to add-on
issues (either true incompatibilities or assumed incompatibilities
based on metadata).

So even if the old point releases were just as frequent as rapid
releases and as frequent in UAC prompts (unless migration from XP to
Windows 7 in the same time frame counts as UAC frequency increase
across the userbase prior to the Maintenance Service), there was a
substantial difference in how they appeared to the user such that
rapid Firefox releases were more intrusive-looking than old Firefox
point releases while Chrome releases were less intrusive-looking.

Part of the intrusiveness comes from the basic problem that
pre-JetPack add-ons touch implementation details in ways that don't go
well with rapid changes to the implementation details. That's a
problem that could not have been fixed before hand and continues to be
unfixable as we continue to pay the "technical debt" in Gecko.
However, intrusiveness that came from reacting to metadata created
ahead of knowledge of true compatibility issues and intrusiveness that
came from not having the stable JetPack API living in Firefox were
things that, in hindsight, could have been addressed (to the extent of
putting the JetPack API onto the Firefox side the way Chrome, Opera
and Safari handle their analogous APIs--not in the sense of waiting
for the JetPack API to become broad enough to cater for all
extensions) along with removing notifications from the update process
before letting to Rapid Releases reach end uses.

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Henri Sivonen
In reply to this post by Chris Hofmann-3
On Sat, Jul 14, 2012 at 6:26 PM, chris hofmann <[hidden email]> wrote:
> In general, users don't like to be annoyed.   A small part of the
> annoyance comes from frequent update dialogs, but a larger
> part of the annoyance comes from breaking addons, breaking
> websites, breaking plugins, and introducing crash problems.
> Until we find ways to get those things under control we won't
> solve this problem.

Do you have insight into how and why we are breaking Web sites these
days compared to the old days?

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Alan Milnes (GP)
In reply to this post by Jono Xia-2
On 13 July 2012 15:20, Jono Xia <[hidden email]> wrote:
> Everybody: I'm sorry. I'm REALLY REALLY sorry.

You shouldn't be - your post was absolutely spot on, that's why it
genereated the interest it did!

Alan
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Jeff Griffiths-4
In reply to this post by Henri Sivonen
On 12-07-14 5:30 AM, Henri Sivonen wrote:
...
> and the stable
> JetPack API lived on the extension side rather than on the Firefox
> side when rapid releases started rolling out (dunno where the stable
> API lives now).

The Jetpack APIs are still on the extensions side ( eg packed in the xpi
) but there is a goal to land Jetpack in mozilla-central, and the first
bit is already in, in the form of the CommonJS loader. It isn't used by
anything and has zero impact currently, but it is a beach-head.

Jeff
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Nicholas Nethercote
In reply to this post by Philip Chee
On Sun, Jul 15, 2012 at 1:50 AM, Philip Chee <[hidden email]> wrote:
>
> Yes but those updates were security updates which meant:
> 1. No change in UI
> 2. No (or almost none) addons broken.

My gut feeling (I have no real data) is that (2) was by far the
biggest problem -- bigger than (1), bigger than changing the meaning
of version numbers, bigger than complaints about copying Chrome, etc.

As for why (2) wasn't anticipated to be a problem?  Maybe we were
overly optimistic about add-on authors being timely with making a
trivial change every 6 weeks?

Nick
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Robert Kaiser
In reply to this post by Henri Sivonen
L. David Baron schrieb:
> But even before rapid release, we were shipping updates to our users
> every six weeks

Every four weeks actually. We slowed the pace of regular updates with
rapid release. ;-)

Robert Kaiser

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Robert Kaiser
In reply to this post by Philip Chee
Nicholas Nethercote schrieb:
> On Sun, Jul 15, 2012 at 1:50 AM, Philip Chee <[hidden email]> wrote:
>>
>> Yes but those updates were security updates which meant:
>> 1. No change in UI
>> 2. No (or almost none) addons broken.
>
> My gut feeling (I have no real data) is that (2) was by far the
> biggest problem -- bigger than (1), bigger than changing the meaning
> of version numbers, bigger than complaints about copying Chrome, etc.

Yes, I have not heard any complaints about UI changes in rapid releases.
All UI change complaints I heard were about the changes we shipped in
Firefox 4, which was before rapid release. And actually, that makes an
argument right against with Philip said: People complain if there is one
huge change at once, they complains less or not at all if there's mall
changes every 6 weeks. At least it feels that way.

> As for why (2) wasn't anticipated to be a problem?  Maybe we were
> overly optimistic about add-on authors being timely with making a
> trivial change every 6 weeks?

We completely underestimated the non-AMO add-ons. We were pretty
confident we could deal with add-on problems because we could just
update compatibility on AMO, and we were pretty good at that. We didn't
realize how many non-AMO add-ons are out there and how much a problem
they produce because we can't just bump their compat.

Robert Kaiser

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Chris Hofmann-2
In reply to this post by Henri Sivonen
On 7/14/12 12:12 PM, Henri Sivonen wrote:

> On Sat, Jul 14, 2012 at 6:26 PM, chris hofmann <[hidden email]> wrote:
>> In general, users don't like to be annoyed.   A small part of the
>> annoyance comes from frequent update dialogs, but a larger
>> part of the annoyance comes from breaking addons, breaking
>> websites, breaking plugins, and introducing crash problems.
>> Until we find ways to get those things under control we won't
>> solve this problem.
> Do you have insight into how and why we are breaking Web sites these
> days compared to the old days?
>
I'm not sure that we are braking sites in new ways, we are just doing it
more often.   We "break sites" when plugin incompatibilities cause
the sites not to work.   We broke sites when we went to a two digit
version number in the UA.   We broke sites when we deprecated features
like global storage and others.  And we break sites when we inject
unintended side effects trying to make improvements.

Just quickly scanning release notes and regression keyword bugs
that made there way to tracking status over the 15 months turns up
a pretty large list that would be an interesting study.
I put together a short sample of somen examples below.

My sense of all this comes from channel meetings and some of the triage
that happens there.

Alex has been interested in gather some data on regressions to figure
out when they happen, when the are detected, and when they are fixed
in the aurora, beta or after ship cycle but gathering that data is a
complicated and time consuming exercise.

Knowing what number and pct. of total regressions are getting addressed
after a release has been shipped might help to tune and engineer the
release cycle to a more optimum interval.   I think this is important,
but that wasn't my main point.  My main point was to try and do
something simple reduce the frequency by which we break users.

-----

*Bug 736731* <https://bugzilla.mozilla.org/show_bug.cgi?id=736731>
-Hotmail no longer auto-updates (due to "globalStorage" removal in fx13
fix on the hot mail side took until  -- 2012-06-27

regession from 10 *Bug 713305*
<https://bugzilla.mozilla.org/show_bug.cgi?id=713305> - WebGL no longer
triggers discrete graphics mode on dual GPU MacBook, affecting content
performance

*Bug 734530* <https://bugzilla.mozilla.org/show_bug.cgi?id=734530>
-Facebook comment box disables spell check
Note that we've broken this in 10, and 11 has already been shipped with
this bug.


#


          Windows Messenger did not load in Hotmail, and the Hotmail
          inbox did not auto-update (764546
          <https://bugzilla.mozilla.org/show_bug.cgi?id=764546>, fixed
          in 13.0.1)

#


#


          Hebrew text sometimes rendered incorrectly (756850
          <https://bugzilla.mozilla.org/show_bug.cgi?id=756850>, fixed
          in 13.0.1)

#


          Flash 11.3 sometimes caused a crash on quit (747683
          <https://bugzilla.mozilla.org/show_bug.cgi?id=747683>, fixed
          in 13.0.1)

#


          Java applets sometimes caused text input to become
          unresponsive (bug 718939
          <https://bugzilla.mozilla.org/show_bug.cgi?id=718939>)

#


          2 digit version number in UA break sites that have poor
          sniffing algorithms

Silverlight video may not play on some Macintosh hardware (715396
<https://bugzilla.mozilla.org/show_bug.cgi?id=715396>)

*Bug 697647* <https://bugzilla.mozilla.org/show_bug.cgi?id=697647>
-flicker on html5/webm video

*Bug 679090* <https://bugzilla.mozilla.org/show_bug.cgi?id=679090> -IPv6
sites broken in Firefox 7

an issue with gov.uk websites (see bug 669792
<https://bugzilla.mozilla.org/show_bug.cgi?id=669792>)


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Alexander Keybl
In reply to this post by Chris Hofmann-3
> Nearly every one of the releases in the last 15 months have required
> a quick X.01 follow up release for a variety of different reasons;
> but the net effect is that we broke a significant number of users
> in significant ways when the bits were put on the wire.

Not to jinx it (especially with some security conferences coming up), but I just want to point out that only one of the last three releases has actually required a .0.1. Also, many of the post-4.0 dot releases were driven by external changes/issues, which can't be blamed on the rapid release process.

Basically, unplanned dot releases are just meant to make the user experience better for our users, and many of the primary drivers aren't in-product regressions. Even still, we're improving our own processes with each release and will continue to do so in the future.

-Alex

On Jul 14, 2012, at 8:26 AM, chris hofmann wrote:

> On 7/14/12 7:46 AM, L. David Baron wrote:
>> On Saturday 2012-07-14 15:30 +0300, Henri Sivonen wrote:
>>> Actually, I think the biggest thing that went wrong with Rapid Release
>>> was the failure to imitate Chrome even more *up front*. Chrome had a
>>> superb silent update system from day one--even before they started
>>> releasing every six weeks. And when Chrome introduced extensions, the
>> But even before rapid release, we were shipping updates to our users
>> every six weeks (with some requiring followup updates to fix
>> regressions); it's just most of those updates were security updates.
>> (Though I guess we didn't stick to the six week cadence as
>> precisely.  I think it was still the goal.)
>>
>> But we were still notifying our users of updates just as often.
>>
>> So I agree that building a less intrusive update system is a good
>> thing, but I don't see how it's related to rapid release.
>>
>> -David
>>
> Yes, we're shipping the same number of releases per year, but
> one of the problems is that under the previous release system
> we were shipping about 1 or 2 releases per year with significant
> regressions that resulted in the need to follow up with a quick
> replacement release.
>
> Nearly every one of the releases in the last 15 months have required
> a quick X.01 follow up release for a variety of different reasons;
> but the net effect is that we broke a significant number of users
> in significant ways when the bits were put on the wire.
>
> Part of this is that we haven't hit the targets for beta and aurora
> populations which would allow us to surface regressions faster
> and get them fixed before shipping to the larger population.
> Work is underway to help fix that, but still not to our original target
> levels.
>
> In general, users don't like to be annoyed.   A small part of the
> annoyance comes from frequent update dialogs, but a larger
> part of the annoyance comes from breaking addons, breaking
> websites, breaking plugins, and introducing crash problems.
> Until we find ways to get those things under control we won't
> solve this problem.
>
> Spreading the releases out on a longer cycle, of say 1 per quarter,
> would result in breaking users about 50% less.  That's the fastest,
> easiest, and biggest immediate impact thing to try if we are trying
> to design a release system that works for users.
>
> -chofmann
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Apology from Jono about that blog post

Stuart Cook-2
In reply to this post by Robert Kaiser
On 16/07/12 12:39 AM, Robert Kaiser wrote:
> Yes, I have not heard any complaints about UI changes in rapid releases.
> All UI change complaints I heard were about the changes we shipped in
> Firefox 4, which was before rapid release. And actually, that makes an
> argument right against with Philip said: People complain if there is one
> huge change at once, they complains less or not at all if there's mall
> changes every 6 weeks. At least it feels that way.

Really? Most UI changes bring some level of negative feedback and angry
forum posts asking how to undo the changes, and there have been plenty
of those changes since 4. Sometimes there's a fix or workaround and
sometimes there isn't. Feathers are being rustled here.

I can't say whether big-bang changes would be better or worse than a
steady stream of small ones, since they both have their pros and cons.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
123