Please advice a way for us: 100,000 clients failed to use Firefox
dbp
release strategy, before Firefox die.
I saw some blog in the web and some posts here already criticize the
problem that rapid release strategy is not working for business
world. I kept watching in past few months. Today, I got a news that
'Firefox 6' is going to ship next week.
Different company, same story
I am an IT specialist in a core IT department of a big firm in Hong
Kong. The department used so many efforts to make some in-house web
applications works with Firefox while one just broke, which was being
used by over 100,000 employees, after Firefox 4 were being used. It
is just no way to justify other division to make the in-house
application work again for Firefox: In view of project management, it
is the problem of a new browser. No one would re-open the project
just aim to make it support with a new browser. The resolution is
simple -- drop the support for Firefox, keep IE alone be the only
supported browser.
I used to be an experienced developer for more than a decade. It is
just too great to deliver a feature-rich, fewer bugs application to
end-users at an earlier time. While the situation in Hong Kong is too
different (and even worse in mainland China). Applications are few to
none support. Don't even think of an in deep UAT would be performed
for every 3 months after the application launched. Many website
projects were developed in WYSIWYG philosophy. In a case when I was
working in another MNC few years ago, I received a website for UAT
which was to be published to public and got 150 errors by just perform
a HTML markup check. Obviously the software house developed the
website was even no idea what 'standard' to be used.
You may criticize me or somebody in charge of development projects
that we should keep an eye over the project, reject what non-
conforming to the standard and make the test-patch cycle more
frequently. The world here is just too competitive. It is always not
enough resources to do the project. It is always too rush to roll-out
before it is mature enough. You may criticize that we should accept
the consequences for not enough funding or time or whatever. What I
am trying to say is: We simply drop the support of Firefox and left
IE alone.
Same old solution
I have no idea why dual branches approach would be an obstacle for a
giant development team as Mozilla Firefox if a small tiny one man band
GPL project could use this approach. I am now managing half dozen of
systems which are running Debian GNU/Linux. A major upgrade from
Lenny to Squeeze do make me trouble for some systems. Even worse, I
have to patch some packages which got trouble when communicating with
other system which is out of my control. After testing for few
months, it is now confirmed stable enough to roll-out.
Boris Zbarsky
> It is just no way to justify other division to make the in-house
> application work again for Firefox: In view of project management, it
> is the problem of a new browser. No one would re-open the project
> just aim to make it support with a new browser.
Given this unwillingness to update the in-house app at all, how would an
LTS branch help?
-Boris
Stormy Peters
large deployments of Firefox and Thunderbird (plus a lot of Mozilla folks)
share best practices for how to manage those deployments. Right now most of
the conversations are around the rapid release strategy.
https://blog.mozilla.com/blog/2011/07/19/announing-mozilla-enterprise-user-working-group/
https://wiki.mozilla.org/Enterprise
Stormy
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
dbp
Sorry that I made a mistake that assume everyone know what causes
problem practically in rapid release.
A stable branch, supposed to release only to fix vulnerabilities,
which everyone should be confident that this application should
interface to whatever 100% seamlessly, say, default output and
configuration defaults. Alternatively, rapid release cannot provide
this seamless interface.
IT department has plan and prepared to update the in-house
applications. Prior to that, you need to justify the needs, acquire
budget for this move, and even hire man-power for the move. After
that, the team can start the project, as said before, you cannot
justify the project because 'the new browser does not support it'.
Fortunately, more or less the business requirements changed everyday
and you can add this 'technical issue' as part of the additional
requirement for the new version of the in-house applications. After
the project delivery, man-power will be released to other projects.
The life-cycle of such business project usually far longer than 3
months. What happened if a new browser released after the in-house
application project was just closed for 1 month? As in the view of
the IT department, you cannot acquire resources immediately. Even
can, you will be criticized by those non-IT heads your professional.
What would you do at that moment? I told u so.
dbp
> We also have a Mozilla Enterprise Working Group where people that manage
> large deployments of Firefox and Thunderbird (plus a lot of Mozilla folks)
> share best practices for how to manage those deployments. Right now most of
> the conversations are around the rapid release strategy.
>
> >https://lists.mozilla.org/listinfo/dev-planning
Thanks Stormy for the reference. I have a check on the site and
unfortunately it need a sign up, with the consent of the corp, which I
am hard to be granted.
The working group and the monthly talk is great that can at least get
the community aware of what the enterprise needs. While when looking
at the agenda of this month regarding rapid release, the gap is just
far too wide.
If I did not make it wrong, the agenda was talking about how to let
the enterprise handle this change. The view from enterprise is far
different, but simple, if there is no way to ensure (or highly sure,
if you criticize) some version of Firefox can be used with the
existing environment, without vulnerabilities of course, we should not
consider this is an option.
Mike Shaver
> I am an IT specialist in a core IT department of a big firm in Hong
> Kong. The department used so many efforts to make some in-house web
> applications works with Firefox while one just broke, which was being
> used by over 100,000 employees, after Firefox 4 were being used.
Firefox 4 wasn't a rapid release, though, so why was it more
problematic than any previous release? Did it break differently in 5?
Mike
Ron Hunter
FF4 was LONG in development, and it changed a LOT of things,
particularly in the UI, that shocked users, and many of them simply
rebelled. FF5, as compared to FF4 was much less traumatic, in that the
UI changed much less, but still garnered its share of rants. Major UI
changes always cause this problem, but that, and the perception in the
minds of users that another change in 6 weeks would be as traumatic,
resulted in a lot of unrest, and dissatisfaction, with Firefox.
I feel this is something Mozilla.org needs to pay a lot of attention to
in the future.
Robert Kaiser
> F5, as compared to FF4 was much less traumatic, in that the
> UI changed much less, but still garnered its share of rants.
I haven't seen *any* rant about specifically FF5.
Any further 6-week releases will be small and mostly untraumatic, that's
the whole point of the new process, next to improved 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 should think about. And most of the
time, I even appreciate irony and fun! :)
Ron Hunter
> Ron Hunter schrieb:
>> F5, as compared to FF4 was much less traumatic, in that the
>> UI changed much less, but still garnered its share of rants.
>
> I haven't seen *any* rant about specifically FF5.
>
> Any further 6-week releases will be small and mostly untraumatic, that's
> the whole point of the new process, next to improved stability.
>
> Robert Kaiser
>
>
it WAS traumatic for many users), here comes FF5 after 6 weeks, and they
were wondering why things were going so fast. I think FF5 and FF6 will
calm most of the 'why the fast updates?' complaints. I surely hope so.
Asa Dotzler
Ron Hunter wrote:
> On 8/16/2011 9:47 AM, Robert Kaiser wrote:
>> Ron Hunter schrieb:
>>> F5, as compared to FF4 was much less traumatic, in that the
>>> UI changed much less, but still garnered its share of rants.
>>
>> I haven't seen *any* rant about specifically FF5.
>>
>> Any further 6-week releases will be small and mostly untraumatic, that's
>> the whole point of the new process, next to improved stability.
>>
>> Robert Kaiser
>>
>>
> Most of the rants were about the fact that after the trauma of FF4 (and
> it WAS traumatic for many users), here comes FF5 after 6 weeks
Firefox 5 wasn't six weeks after Firefox 4. It was several months.
Firefox 6 is the first release that's approximately on the new cycle. 5
couldn't be because we had to load all the trains before we could get to
the new cadence.
- A
Steve Wendt
> Firefox 5 wasn't six weeks after Firefox 4. It was several months.
It was 3 months (dates on the FTP directories are 3/22 and 6/21), but to
many people it seemed far less, because they didn't update to 4
immediately (OMG, it's different! My extensions aren't available!).
Jonas Sicking
I don't think anyone is doubting that the new release schedule is hard
for a lot of enterprises, and even some users (due to extension
incompatibility etc). However it also comes with a lot of advantages
in bringing improvements to users and the web platform sooner. So
neither suggestions that we abandon the rapid releases, or suggesting
that the current solution is ideal for everyone is very productive.
For enterprises that want to help us find a solution that works for
everyone, I suggest that you join the Mozilla Enterprise Working Group
and work with them to find a solution that works for you.
/ Jonas
ya knygar
> I feel this is something Mozilla.org needs to pay a lot of attention to in the future.
A bit of off-topic but this topic seems like ending anyway,
and - what i'm going to write - relates to release policy - directly.
As an UI-UX designer
I think - there are functions that appear in a process of Firefox
evolution and there aren't much complain and won't be,
but there are interfaces for these features that appears here and
there and changing not only by adding itself somewhere
but by changing the defaults, by that - insulting habits.
I think - it could be solved by giving the UI and by that UX - that
would variate, depending on people's needs.
As a dedicated Linux user I'v seen and you, probably, also - a lot of
topics criticizing Gnome, KDE, Unity etc.
changes, calling it a disaster or kind. Latest Firefox ain't gaining
such a terrible reviews but it is, also - a much smaller
project as for UI and UX effect. Anyway - i feel that such a changes
are anyway - better than constant environment and experiences.
But my view, probably, doesn't matter.
What i feel - should matter - is a real UX of hundreds of millions
Mozilla users.
By that - i think - B2G, Chromeless or these kind of projects could
finally help
the end-users by providing an ultimate ability to theme all into a
very different,
variable, user-depended environments..
Such as a theme of one browser, a theme of another, a theme of FF3 and
FF4 along
with a latest theme of FFX. UX would depend, controls would be
re-arranged elsewhere,
some would be even restricted seamlessly,
URLs would be one or other, tabs would reflect or not.
There are always an infinity of variants for everything, including
final rendering of content,
that would suit one or another person - differently. And i,
personally, like the kind
of "an Ultimate" about:config or let's say - Firefox terminal or
config file - where you could change
what is, anyway - fully hidden and unchangeable in a "standard" interface.
This "standard" is, actually a problem, as i see.
Firefox is great at most not by default design and feature set,
but for great rendering (at least - solid and fast enough)
and extensibility. Ain't it?
What I mean exactly - is a future - where people could receive exactly what
they need by a combined add-ons+themes+persona affords.
I kind of pill that in one take - makes the completely new experience
and there would be a pill for corporate users and other kinds.
The Wonderland kinds of pills, ofc.
Other variants:
- config files, these were helpful for years,
generated config files, easily up-datable from auto
corporation-grade-Sync service - config files.
- versions - what is wrong with it? in OS's you could have some secure
or not so - sandboxes
for an old programs and staff. That is like they often make the
backwards compatibility
to work, not by stopping the evolution.
Why - for a corporations there aren't some Corporazilla with two-three
of popular versions
of XULR and staff,
that *even* could start just as another tab if the version's need detected.?
I guess the size of distribution won't stop the corporations.
- ask me, personally :)
That is what i think mainly for UI-UX, but it could be transcripted
to other software-evolution related problems.
-
Different view:
What i think - for the worst case -
For backwards compatibility - it could be far more difficult.
There are situations like with Prism programs (just for example),
abandoned Site-Specific-Browsers that needs to be updated due to a
security or performance
or any other problems. (corporations - remember - you had largely used
a browsers like IE6
that was 9-6-3 years outdated and all was like ok, even without
add-on's at all :)
I think - with Mozilla or any rapidly and widely evolving project - it
would be like this.
It actually - like this for most.
If you need a more stable environment - you'd better use some
framework like.. hm..
i don't know any cool that doesn't brake something as a normal case of
production.
Are you?
In best case - there would be a loud shout about some freezing,
warming or being deprecated API.
The same goes for other software stacks, BTW. That is a problem that,
i think, could only
be resolved with ... magic that would migrate the old realizations to
new environments.
Somewhere that magic could occur if for all these 100 000 of workers
would be paid a, well,
10 cents each could be enough for some Mozilla developer..
Asa Dotzler
ya knygar wrote:
> What I mean exactly - is a future - where people could receive exactly what
> they need by a combined add-ons+themes+persona affords
This is in the roadmap for Firefox. The UX team gave a public
presentation on just such a feature two weeks ago. You may be able to
find more participation on this kind of topic in the UX or Firefox lists
rather than the mozilla dev planning list.
- A
Asa Dotzler
ya knygar wrote:
> What I mean exactly - is a future - where people could receive exactly what
ya knygar
haven't seen it on
http://planet.firefox.com/ux/
could you provide the link please?
maybe i haven't heard about as
i usually doesn't participate in inner
meeting and staff, because i'm not so inner
and i can't use Mozilla's IRC to pry in, because it blocks
my Tor :)
PS: i'll move that discussion off this list, ofc.
dbp
I am not in the development team, so I could not tell you in detail
what causes the problem in FF5 from that application -- it just
broke. From my previous experience in development, that usually
occurred due to API and default behaviour change, which is quite sure
would cause some external components depends on it get problem. This
problem can be eliminated 99.9% by dual branches approach.
For those who wonder, the remaining 0.1% is due to those external
components relying on the characteristics that was changed in the
stable branch, in other words, both relying on the characteristics of
the vulnerabilities.
Robert Kaiser
> Most of the rants were about the fact that after the trauma of FF4 (and
> it WAS traumatic for many users), here comes FF5 after 6 weeks, and they
> were wondering why things were going so fast. I think FF5 and FF6 will
> calm most of the 'why the fast updates?' complaints. I surely hope so.
Right, that's why I said I haven't heard any about FF5 specifically.
Stanimir Stamenkov
> I am not in the development team, so I could not tell you in detail
> what causes the problem in FF5 from that application -- it just
> broke.
Is it a Web application, or is it an application based on the
Mozilla platform (e.g. XULRunner)? If it is an Web application,
even if it is meant for just Intranet use, it should be written so
it is compatible with at least couple of major modern browsers.
Tying compatibility to proprietary/experimental features of just one
browser (and browser version) doesn't seem wise for maintaining a
long term Web/browser application support.
--
Stanimir
dbp
This is correct attitude but infeasible in practice. The cause and
consequences sum up from the lengthy thread is:
Facts:
1. The life cycle of software development in business world is much
longer than 3 months. I would say 2 years as a fair time.
2. The software development team are resources that need lengthy time
to plan and be allocated.
3. Rapid release strategy introduced not only bug fixes and security
fixes, but feature enhancement. In other words, more bugs or chance
of incompatibility.
Consequences:
1. The web application has higher chance to break round the year,
which used to be only in major software upgrade before.
Resolution:
1. Increase budget to let software development team reserve resources
to standby round the year.
2. Drop the support of the browser which got higher chance of
incompatibility at unplanned time.
Asa Dotzler
I think you mis-understand how Mozilla development and browser updates
work. We try equally hard with every single release, whether it's a
security only release or a feature release, to not break compatibility
with Web content.
It turns out that it's our security fixes which are the less well tested
and more likely to break web content than many of the feature fixes we take.
Your risk between Firefox updates today of having a well-coded Web
application break are probably not significantly worse than it was last
year taking our security updates every 6 weeks.
- A
Stanimir Stamenkov
> Facts:
>
> 1. The life cycle of software development in business world is much
> longer than 3 months. I would say 2 years as a fair time.
The company I work for has a three weeks release cycle. It is
essentially the same as with current Mozilla - we have two staging
periods, like aurora and beta, and one roughly analogous to nightly.
During these periods, features which could have been developed and
tested for longer time prior that, get integrated and tested
together prior release. We're using this process from the beginning
(with small adjustments over time) and it is required to address the
needs of fast evolving business.
> 2. The software development team are resources that need lengthy time
> to plan and be allocated.
Yes, we plan on features which usually take longer than one release
cycle to develop fully. Those features are developed and tested on
separate environments prior "getting on the release train".
> 3. Rapid release strategy introduced not only bug fixes and security
> fixes, but feature enhancement. In other words, more bugs or chance
> of incompatibility.
As explained elsewhere, the rapid release strategy itself doesn't
hurt the quality.
--
Stanimir
Boris Zbarsky
> I think you mis-understand how Mozilla development and browser updates
> work. We try equally hard with every single release, whether it's a
> security only release or a feature release, to not break compatibility
> with Web content.
I don't think this is actually true... we certainly accept web-facing
changes on m-c that would not have been accepted in a Gecko 1.9.2.x release.
> Your risk between Firefox updates today of having a well-coded Web
> application break
dbp's already pointed out that enterprises have a huge preinstalled base
of poorly-coded not-quite-web applications....
There's a real problem that could use solving here, at least in the
short term. Let's not just pretend it doesn't exist.
-Boris
Chris Hofmann
> Wed, 17 Aug 2011 21:22:58 -0700, /dbp/:
>
>> Facts:
>>
>> 1. The life cycle of software development in business world is much
>> longer than 3 months. I would say 2 years as a fair time.
>
> The company I work for has a three weeks release cycle. It is
> essentially the same as with current Mozilla - we have two staging
> periods, like aurora and beta, and one roughly analogous to nightly.
> During these periods, features which could have been developed and
> tested for longer time prior that, get integrated and tested together
> prior release. We're using this process from the beginning (with
> small adjustments over time) and it is required to address the needs
> of fast evolving business.
>
Yes, the point here is that organizations are able to adopt technology
at a wide variety of paces. Its been demonstrated that 2 years is much
to slow for an organization to stay competitive and safe. In 2004 if
you had a fully patched IE 6 you were exposed to a wide variety of
attacks exploiting ActiveX. It took Microsoft another two to release
IE7 with substantial changes that restricted ActiveX to provide the
protections needed for a wide variety of drive-by attacks. It took
several more years for large organizations to adopt IE7, 8, and 9 and
other modern web browsers. I'll argue that the companies that moved
this slow in adopting new technology aren't competitive in their
industries.
On the other hand +20% of all enterprises have adopted Firefox
(according to studies listed here [1]) and do have systems and process
in place to adopt technology at a faster pace. These are the kinds of
organizations that we are most interested in working with, and we also
want to listen to ways that help companies adopt technology and changes
to modern browsers at a faster pace. We believe that advancing the
state of browser technology at a quick pace is critical to the health
and advancement of the internet.
[1]
https://wiki.mozilla.org/Deployment:Deploying_Firefox#Marketshare_in_the_Enterprise_and_Business
>> 2. The software development team are resources that need lengthy time
>> to plan and be allocated.
>
> Yes, we plan on features which usually take longer than one release
> cycle to develop fully. Those features are developed and tested on
> separate environments prior "getting on the release train".
>
>> 3. Rapid release strategy introduced not only bug fixes and security
>> fixes, but feature enhancement. In other words, more bugs or chance
>> of incompatibility.
>
> As explained elsewhere, the rapid release strategy itself doesn't hurt
> the quality.
And an important idea here is how we might work together to reduce that
lengthy plannning and test time and spot compatibility problems earlier.
How can you abstract test cases that identify key pieces of internal
apps that you test over and over with each browser security and
functional update?
And how can we integrate test cases like that into our test suites so
the planing and testing that you do now can be leveraged and shared by
others?
-chofmann
Robert Kaiser
> On 8/18/11 12:22 AM, Asa Dotzler wrote:
>> I think you mis-understand how Mozilla development and browser updates
>> work. We try equally hard with every single release, whether it's a
>> security only release or a feature release, to not break compatibility
>> with Web content.
>
> I don't think this is actually true... we certainly accept web-facing
> changes on m-c that would not have been accepted in a Gecko 1.9.2.x
> release.
That might be two different things, as we wouldn't even have accepted
new features that don't interfere in any way with any existing web
content in 1.9.2.x, but those still don't break compatibility with web
content, as Asa assures.
From what I've seen - but you surely know better - we try very hard to
not break any existing web content with anything we're introducing to
the web-facing API at any time. That's what Asa says above, as I
understand it. Do you disagree?
Kyle Huey
> From what I've seen - but you surely know better - we try very hard to not
> break any existing web content with anything we're introducing to the
> web-facing API at any time. That's what Asa says above, as I understand it.
> Do you disagree?
We do intentionally make backwards incompatible changes when we believe that
the benefit of making the change for the web exceeds the cost. (e.g. Bug
6799731, Bug 661876, Bug 672395, Bug 649672). We don't do this lightly, but
we do intentionally break existing web content at times.
- Kyle
Jonas Sicking
> Boris Zbarsky schrieb:
>>
>> On 8/18/11 12:22 AM, Asa Dotzler wrote:
>>>
>>> I think you mis-understand how Mozilla development and browser updates
>>> work. We try equally hard with every single release, whether it's a
>>> security only release or a feature release, to not break compatibility
>>> with Web content.
>>
>> I don't think this is actually true... we certainly accept web-facing
>> changes on m-c that would not have been accepted in a Gecko 1.9.2.x
>> release.
>
> That might be two different things, as we wouldn't even have accepted new
> features that don't interfere in any way with any existing web content in
> 1.9.2.x, but those still don't break compatibility with web content, as Asa
> assures.
>
> From what I've seen - but you surely know better - we try very hard to not
> break any existing web content with anything we're introducing to the
> web-facing API at any time. That's what Asa says above, as I understand it.
> Do you disagree?
I disagree. While we generally work very hard on not breaking any
significant number of pages, we most certainly do change behavior in
ways that we know risks breaking pages.
For example we do on occasion remove features which don't appear to be
gaining traction on the web, or which are old and crufty and which we
think do more harm than good.
Another example is un-prefixing features, or change features which are prefixed.
Thirdly, we fix bugs in existing features. This can be aligning us
with specifications or other browsers, or simply aligning us with
sanity.
All of these cases risks breaking, and do break, content. In all cases
we try to not break too large amount of content and if we find out
that we do, we try to find an alternative solution. However in all
cases we are ok with small amount of breakage (for some definition of
small), and we might not find out about even large amount of breakage
until after release.
This is not a new strategy, this is how we've always done things.
What's new is that these breakages can now come every 6 weeks as
opposed to every 12 months. It's certainly a smaller number of
breakage-risking changes every 6 weeks, but it's more than zero.
So I have full understanding for wanting to QA every release cycle,
and that QAing every 6 weeks is a pain.
/ Jonas
Boris Zbarsky
> That might be two different things, as we wouldn't even have accepted
> new features that don't interfere in any way with any existing web
> content in 1.9.2.x, but those still don't break compatibility with web
> content, as Asa assures.
Sorry, but that's bunk. Adding a click() method on anchors broke web
content to the point that we considered a chemspill. Adding a "form"
attribute to inputs broke web content to the point that we considered
changing the HTML5 spec on the matter. Adding any new IDL property on
input or form tags or on document elements risks breaking on*
attributes, and we have had several examples of such breakage in the
past (most notably the addition of the "list" attribute on <input>).
Adding new features risks breaking web content as long as the features
have names that are at all meaningful and hence likely to be used on the
web. The only question is how much content is broken and whether it's
worth the new feature.
> From what I've seen - but you surely know better - we try very hard to
> not break any existing web content with anything we're introducing to
> the web-facing API at any time. That's what Asa says above, as I
> understand it. Do you disagree?
Asa says something much stronger, and what he says just isn't true.
But even what you said above is just not true, as Jonas notes.
Again, please let's stop pretending this problem doesn't exist.
-Boris
Rob Sayre
>>
> Most of the rants were about the fact that after the trauma of FF4 (and
> it WAS traumatic for many users), here comes FF5 after 6 weeks, and they
> were wondering why things were going so fast. I think FF5 and FF6 will
> calm most of the 'why the fast updates?' complaints. I surely hope so.
Hopefully. Here's an article from 2003(!) explaining why gradual changes
with a goal in mind are better than doing everything at once.
http://www.uie.com/articles/death_of_relaunch/
****
eBay.com: Satisfying their Users with Gradual Evolution
===
At eBay, they learned the hard way that their users don't like dramatic
change. One day, the folks at eBay decided they no longer liked the
bright yellow background on many of their pages, so they just changed it
to a white background. Instantly, they started receiving emails from
customers, bemoaning the change. So many people complained, that they
felt forced to change it back.
Not content with the initial defeat, the team tried a different
strategy. Over the period of several months, they modified the
background color one shade of yellow at a time, until, finally, all the
yellow was gone, leaving only white. Predictably, hardly a single user
noticed this time.
****
I think the main thing to remember is that Firefox can't support
everything in perpetuity, especially features that didn't really catch
on. But, when things do break, the Mozilla community needs to be sure we
have a precise understanding of the breakage. It's a hard problem--hard
enough to be suspicious of any "best of both worlds" proposal, like
supporting an LTS release. We already have quite a game of Katamari
Damacy on our hands.
Incidentally, this is why the rapid release process has such stringent
criteria for landing patches on Aurora and Beta. It is extremely
difficult to make good decisions on these issues under time pressure.
When you have a patch that improves something incrementally for the vast
majority of users (e.g. memory footprint), it /could/ cause horrible
breakage for some small set of users (e.g. Slovenian banks running
obsolete SunONE application servers). You don't want to be making those
calls on a two-to-four-week timeline.
- Rob
Ron Hunter
But why should the rest of the world's users wait on a Slovenian bank
running ancient servers?
Rob Sayre
>
> But why should the rest of the world's users wait on a Slovenian bank
> running ancient servers?
Oh, I didn't say they should. What I did say is that it might take some
time to figure out, so the clamp on changes in Aurora and Beta needs to
be held tight. That way, these decisions aren't encountered late in the
game.
- Rob
Asa Dotzler
We do not break the web when we're making web-facing changes except for
the occasional security concern, something we'd do in a stability
release if it was a big deal. We break the web regularly on security
updates (I've read dozens of reports of our security updates breaking
things, including widely distributed JS libraries and richtext editors
and whatnot)
I think our track record of not breaking the web on major releases is as
good or maybe even better than on security releases.
Finally, yes, there is a problem that could use solving here. I don't
think solving this problem even borders on critical to Mozilla's
mission. We took out of process plug-ins into the 3.6.4 security and
stability update. That was the right call in forwarding our mission. It
was the wrong call for supporting managed deployments. That's how we
should behave going forward. Enterprises have never been our focus and I
assert that focusing on them is not the best way to spend our resources
against our Mission.
- A
Boris Zbarsky
> We do not break the web when we're making web-facing changes except for
> the occasional security concern
That really depends on your definition of "break the web"...
We most certainly break _websites_ all the time.
We try to not break too many of them too much, hopefully.
Historically, your claim that "We try equally hard with every single
release, whether it's a security only release or a feature release, to
not break compatibility with Web content" is most certainly not true.
We tried much harder for security releases.
> We break the web regularly on security updates
Yep.
> I think our track record of not breaking the web on major releases is as
> good or maybe even better than on security releases.
My experience, admittedly anecdotal, does not point in that direction.
Do you have any data to back this (somewhat extraordinary, imo, since
the major releases typically include the breaking changes from the
security releases) claim up?
> Finally, yes, there is a problem that could use solving here. I don't
> think solving this problem even borders on critical to Mozilla's
> mission. We took out of process plug-ins into the 3.6.4 security and
> stability update. That was the right call in forwarding our mission. It
> was the wrong call for supporting managed deployments. That's how we
> should behave going forward. Enterprises have never been our focus and I
> assert that focusing on them is not the best way to spend our resources
> against our Mission.
Yes, I'm well aware of your opinions on the matter. I don't necessarily
agree with them.
But at the moment, I'd just like us to be clear on the facts of past and
present release behavior, just so there's no confusion on _that_,
without getting into the interpretation and future planning rathole.
And those facts as I see them are that every update we make typically
contains changes that break _some_ website. There are, furthermore,
more of those sorts of changes in the current rapid releases, typically,
than there were in the old-style security updates, even given that some
of those securit updates had some pretty major changes. The only
question for us is how many websites break and which ones. The only
question for a corporate deployment is whether the breakage is likely to
include one of their internal apps.
Are we at least in agreement on that much? If not, I'd like to
understand which parts of the preceding paragraph you disagree with...
-Boris
Asa Dotzler
> But at the moment, I'd just like us to be clear on the facts of past and
> present release behavior, just so there's no confusion on _that_,
> without getting into the interpretation and future planning rathole.
>
> And those facts as I see them are that every update we make typically
> contains changes that break _some_ website. There are, furthermore, more
> of those sorts of changes in the current rapid releases, typically, than
> there were in the old-style security updates, even given that some of
> those securit updates had some pretty major changes. The only question
> for us is how many websites break and which ones. The only question for
> a corporate deployment is whether the breakage is likely to include one
> of their internal apps.
>
> Are we at least in agreement on that much? If not, I'd like to
> understand which parts of the preceding paragraph you disagree with...
Sure. I'll go along with that.
We never didn't break any enterprises with our security updates and
we'll never not break some enterprises with our rapid release updates.
Sounds to me like Firefox really isn't a good solution for most
enterprises and never really has been.
- A
Boris Zbarsky
> We never didn't break any enterprises with our security updates and
> we'll never not break some enterprises with our rapid release updates.
That's fine. If you note, my post was talking about "how likely", not
whether it happens at all. Lack of breakage is never guaranteed. Heck,
a company could get a corrupted download which doesn't get noticed
because the corrupted binary just happens to hash the same as the
correct one while still running, and the corruption could break their
internal apps. But the probability of that is pretty darn low and
people are willing to take that chance, I bet.
So while you and I agree on the claim above, it's a pretty vacuous
claim. In my opinion. It falls into about the same bucket as claiming
that we could all be dead tomorrow for various reasons so there's no
point doing anything today.
> Sounds to me like Firefox really isn't a good solution for most
> enterprises and never really has been.
_That_ depends entirely on their risk tolerance and on how likely
updates were (and are) to break their webapps. In particular, this
conclusion does not follow from the above premise that we agree on.
-Boris
Rob Sayre
>
> And those facts as I see them are that every update we make typically
> contains changes that break _some_ website. There are, furthermore, more
> of those sorts of changes in the current rapid releases, typically, than
That sounds likely, but I think it is premature. It is too early to
characterize Firefox 6, and Firefox 5 didn't have that many risky
changes. Certainly less than some of the 3.6.x series.
But! There is no accompanying buildup of what one might call "break the
Web debt", where some huge batch of unrelated changes lands with all
sorts of fall out. There will be risky things, like new JITs and new GFX
backends, but not a year's worth.
Of the major releases I was involved in, I think only Firefox 4 did
reasonably well on Web compatibility. But it had good automation, and,
uh, plenty of time for testing.
- Rob
Boris Zbarsky
>> And those facts as I see them are that every update we make typically
>> contains changes that break _some_ website. There are, furthermore, more
>> of those sorts of changes in the current rapid releases, typically, than
>> there were in the old-style security updates...
>
> That sounds likely, but I think it is premature. It is too early to
> characterize Firefox 6, and Firefox 5 didn't have that many risky
> changes. Certainly less than some of the 3.6.x series.
Sure. It had more than the average 3.6.x release, though, and broke
more sites.
> But! There is no accompanying buildup of what one might call "break the
> Web debt", where some huge batch of unrelated changes lands with all
> sorts of fall out.
Right. I'm not arguing against the rapid release process; I'm arguing
against ostrich-style cheerleading and misrepresentation of the truth.
-Boris
Boris Zbarsky
>> understand which parts of the preceding paragraph you disagree with...
>
> Sure. I'll go along with that.
>
> We never didn't break any enterprises with our security updates and
> we'll never not break some enterprises with our rapid release updates.
I've had a chance to think this over some more, and I think you
fundamentally misunderstand the problem I had with your 8/18/2011 post
in this thread.
My point was simply that you made factual claims about how our
web-facing code is developed that are not true. I'm not so much
interested in discussing the conclusions you draw from those claims,
because I think we fundamentally disagree on them no matter what the
basis for those conclusions and rehashing that disagreement is not
really productive. But I _am_ interested in people making claims about
our developments operations not misrepresenting how we actually go about
things.
That means not claiming that we preserve web compat at all costs. That
means not claiming that we're the best in memory usage in all situations
right now. There are various other clearly bogus claims along similar
lines that I've seen bandied about recently.
In practice that means either not making sweeping statements or checking
with someone actually familiar with the relevant code area (say Jonas
for web compat stuff) to make sure they're true before making them.
I'm tired of these various outright lies (and that's exactly what they
are!) being repeated over and over, and I really wish people would stop
and think about what they're saying before making blanket claims that
are so clearly untrue... Since the people who tend to do that are
usually a lot louder than the people who actually know what's going on
(what's the last time Jonas got quoted all over the tech press?), people
build an impression of our project based on their statements. And that
impression, if you look at it from outside, is not a good one, and that
hurts us in terms of finding contributors and gaining/keeping mindshare.
And it really does hurt us. As a simple recent example, the blanket
claim "Firefox 6 is 20% faster" hurts us when people then go and run a
single benchmark (Peacekeeper in this case) and report that it's
actually slower than Firefox 5 on that benchmark and people get the
impression that we lie about our performance claims. And in that case,
I'm pretty sure _we_ didn't even make the claim; it was just someone
misunderstanding our startup improvement numbers to somehow be relevant
to Peacekeeper... but we did nothing to counter the "Firefox 6 will be
20% faster" headlines, and then the people writing later articles only
read those headlines and not our press copy. We could try to do better
in situations like that, but we sure shouldn't go out of our way to
_create_ them.
-Boris
Boris Zbarsky
> we'll never not break some enterprises with our rapid release updates.
And one more thing. I was very clearly talking about website breakage.
That includes enterprise intranet apps, but it also includes things
like tsp.gov being broken by the addition of @form [1], which is a
problem for our users (in this case of the "can't log in to manage my
retirement account" variety). I expect this to be a temporary problem
in that eventually the site will get fixed, but it's been a "temporary"
problem for over a year now, and almost 6 months for release builds...
This sort of thing is a real issue our users do and will hit, and just
because we don't have a solution for it right now doesn't mean we
shouldn't consider ways to solve it.
-Boris
timeless
they deploy and use will not be perfect and be willing to collect bug
reports at any time. Some bugs were probably always present and may
just be unreported, some may have accidentally worked with some
browsers or be cases of poorly designed hacks for specific browsers.
Sure Mozilla will make two releases a year, but there are also
potentially 6 Chrome releases, a Safari release or two, a release or
two of IE, releases of Opera, updates to any of these and mobile
platform updates. No matter what, your web sites will never have
exactly one software change a year to deal with. Nor will your users
ever encounter a bug free site.
I recently changed employers. My new employer has a simple way for me
to report a bug about any service. They take that report and assign it
to the correct team. The team can prioritize it by severity (prevents
me from doing work) or by impact (affects many users).
Sure users will have some impact from your buggy applications, but the
ones who report problems will be willing to help test to improve
things. They might even be happy to do so (I certainly am).
As users in enterprises are made more involved, they're empowered and
can feel/see positive improvement in sites they use. The same applies
to programs. I'm glad to get Firefox 6 (I just visited someone earlier
this week using 3.6.17 and we had a few updates - 3.6.20, 5.0.1, 6 -
but it worked, and it made things faster - including potentially
disabling the Skype toolbar and insecure versions of Flash*).
* I had actually already disabled and upgraded them, but noted that it
would have improved these things automatically.
On 8/18/11, Jonas Sicking <jo...@sicking.cc> wrote:
> On Thu, Aug 18, 2011 at 10:56 AM, Robert Kaiser <ka...@kairo.at> wrote:
>> Boris Zbarsky schrieb:
>>>
>>> On 8/18/11 12:22 AM, Asa Dotzler wrote:
>>>>
>>>> I think you mis-understand how Mozilla development and browser updates
>>>> work. We try equally hard with every single release, whether it's a
>>>> security only release or a feature release, to not break compatibility
>>>> with Web content.
>>>
>>> I don't think this is actually true... we certainly accept web-facing
>>> changes on m-c that would not have been accepted in a Gecko 1.9.2.x
>>> release.
>>
>> That might be two different things, as we wouldn't even have accepted new
>> features that don't interfere in any way with any existing web content in
>> 1.9.2.x, but those still don't break compatibility with web content, as
>> Asa
>> assures.
>>
>> From what I've seen - but you surely know better - we try very hard to not
>> break any existing web content with anything we're introducing to the
>> web-facing API at any time. That's what Asa says above, as I understand
>> it.
>> Do you disagree?
>
> I disagree. While we generally work very hard on not breaking any
> significant number of pages, we most certainly do change behavior in
> ways that we know risks breaking pages.
>
> For example we do on occasion remove features which don't appear to be
> gaining traction on the web, or which are old and crufty and which we
> think do more harm than good.
>
> Another example is un-prefixing features, or change features which are
> prefixed.
>
> Thirdly, we fix bugs in existing features. This can be aligning us
> with specifications or other browsers, or simply aligning us with
> sanity.
>
> All of these cases risks breaking, and do break, content. In all cases
> we try to not break too large amount of content and if we find out
> that we do, we try to find an alternative solution. However in all
> cases we are ok with small amount of breakage (for some definition of
> small), and we might not find out about even large amount of breakage
> until after release.
>
> This is not a new strategy, this is how we've always done things.
> What's new is that these breakages can now come every 6 weeks as
> opposed to every 12 months. It's certainly a smaller number of
> breakage-risking changes every 6 weeks, but it's more than zero.
>
> So I have full understanding for wanting to QA every release cycle,
> and that QAing every 6 weeks is a pain.
>
> / Jonas
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Sent from my mobile device
PhillipJones
Your not realizing that alienating Enterprise users also affect regular
users as well. If a person in Enterprise discovers that FireFox has
Problems at work. What do you think they will do at home. And if they
tell their experiences at work to friends out side of work. Then Those
people are going to dump FF as well.
--
Phillip M. Jones, C.E.T. "If it's Fixed, Don't Break it"
http://www.phillipmjones.net mailto:pjo...@kimbanet.com
hartnegg
> We try equally hard with every single release, whether it's a
> security only release or a feature release, to not break compatibility
> with Web content.
>
> It turns out that it's our security fixes which are the less well tested
> and more likely to break web content than many of the feature fixes we take.
>
> Your risk between Firefox updates today of having a well-coded Web
> application break are probably not significantly worse than it was last
> year taking our security updates every 6 weeks.
Implementing only the required security fixes has definitely a smaller
chance to break something, than implementing these fixes and
additionaly some new features.
Also if a security fix breaks something, people are more likely to
accept that, than when a new feature breaks something. Also boss is
more likely to accept ITs excuse to quickly install an update, when it
was an important bug fix.
Previously when for example 3.6.0 came out and broke something, people
had the choice to stay on 3.5.x until the problem was solved, and
switch to 3.6.x whenever it was appropriate for them. Now they are
forced to switch from 6 to 7 at the time that you choose, regardless
how many problems this causes to them.
Without a LTS version, it's a lot more risky for an IT department to
support firefox at all. Because when something breaks, they have to
justify their decision to use Firefox. If they see the beta to break
something, they have a mere 6 weeks to find and implement a solution.
Regardless how much other work they happen to have on their schedule
for these 6 weeks. They know in advance, that this will eventually
happen if they keep supporting Firefox. Ok, you do smaller steps
today, but even a tiny change in one place can cause a lot of work to
adapt to in another place. We all know murphys law. It will happen.
Thus they are very inclined to drop firefox support regarless of what
your estimate is how big this chance is. If they don't want to risk
loosing their job, they can't do that.
regards,
Klaus Hartnegg
Asa Dotzler
> Without a LTS version, it's a lot more risky for an IT department to
> support firefox at all
No disagreement there. The rapid release cycle makes things more
difficult (and sometimes impossible) for some managed deployments.
This was the unfortunate trade-off we made in order to move Mozilla's
organization and products to a cadence that would allow us to continue
to lead the Web forward and to best advance our mission of building user
sovereignty and a deeply compelling and competitive Web platform.
There are some discussions happening in a group called the Mozilla
Enterprise Working Group that are seeking more information from people
who manage deployments and working to figure out if there are
mitigations for some of those pain points that are compatible with our
new rapid cadence and our overall Mozilla Mission.
You can read more about the Enterprise Working Group here:
http://blog.mozilla.com/blog/2011/07/19/announing-mozilla-enterprise-user-working-group/
- A
Wes Garland
> Sounds to me like Firefox really isn't a good solution for most enterprises
> and never really has been.
>
Asa, I don't understand why you keep up with this hyperbole.
While it may be true that not focusing on The Enterprise is the smart move
from Mozilla's POV, I just can't see how actively dissuading enterprises can
in any way advance The Mission.
I believe the message we SHOULD be telling enterprises is: IF you develop
standards-compliant web applications, Firefox will run them, and updates are
incredibly unlikely to break them.
Just be absolutely clear: not all enterprises run poorly-written,
web-incompatible software, and I believe that those which *do* should be
encouraged to upgrade their stack to something which *does* adhere to
standards. This change can be at least partly achieved through simple
evangelism, but it is very difficult to suggest a solution including Firefox
to any enterprise when there are loud voices at Mozilla actively alienating
the sector.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Asa Dotzler
> I believe the message we SHOULD be telling enterprises is: IF you develop
> standards-compliant web applications, Firefox will run them, and updates are
> incredibly unlikely to break them.
Agreed. You are 100% correct.
That is precisely the message we should be sending to those who will
listen. "You can manage with our new model. It is possible." To those
who respond with "no, absolutely not, you're no good for me" or "you
must change in this way to accommodate me" though, I think it's
reasonable to follow up with "you may be right. we may not be any good
for you." and move on to trying to convince the next person.
(But do be careful about saying things like "updates are incredibly
unlikely to break them." I was saying similar things and I've since been
taken to the woodshed by Gecko owners who say this is not true and that
there are plenty of circumstances where we will both knowingly and
unknowingly break them.)
- A
Boris Zbarsky
>> I believe the message we SHOULD be telling enterprises is: IF you develop
>> standards-compliant web applications, Firefox will run them, and
>> updates are
>> incredibly unlikely to break them.
>
> Agreed. You are 100% correct.
>
> That is precisely the message we should be sending to those who will
> listen. "You can manage with our new model. It is possible." To those
> who respond with "no, absolutely not, you're no good for me" or "you
> must change in this way to accommodate me" though, I think it's
> reasonable to follow up with "you may be right. we may not be any good
> for you." and move on to trying to convince the next person.
That seems perfectly reasonable to me, fwiw.
> (But do be careful about saying things like "updates are incredibly
> unlikely to break them." I was saying similar things and I've since been
> taken to the woodshed by Gecko owners who say this is not true and that
> there are plenty of circumstances where we will both knowingly and
> unknowingly break them.)
_If_ we're talking about a standards-compliant web app, then the chance
of an update breaking it is low, I think.
Just to be clear, I believe the following statements are both true:
1) The chance of an update breaking some site somewhere is not that
low (which is what makes the claim "we try to never break any
sites" false imo).
2) The chance of an update breaking HTML that's written carefully is
very low.
Looking at my breakage examples from earlier in this thread, the @list
breakage would have broken even careful sites that happened to put
enough code in inline handlers; we should probably publicise it as good
authoring practice to minimize the amount of code in event handlers for
future-proofing. But the addition of @form only broke sites that had
markup like this:
<input </form>
(note missing '<' on the input tag). The addition of click() on anchors
only broke sites that tried to fake links using non-link elements of
some sort and ran different code in different browsers to work around an
ancient IE bug.
The other source of breakage, of course, is changes to experimental
features. Use of those in pages doesn't really fall under
"standards-compliant" imo. It's not necessarily easy to get away from
them yet, but as time goes on and more things stabilize it should get
easier and easier....
So I think that a page that doesn't browser-sniff and uses some basic
best practices (avoiding inline event handlers), works in all current
browsers, and actually passes Henri's HTML validator so that there are
no parsing gotchas should be pretty future-proof.
-Boris
Jesper Kristensen
> So I think that a page that doesn't browser-sniff and uses some basic
> best practices (avoiding inline event handlers), works in all current
> browsers, and actually passes Henri's HTML validator so that there are
> no parsing gotchas should be pretty future-proof.
Do we have an MDN article about writing future-proof websites? I don't
think we have, and when I have been asked about how to future-proof a
website recently, I have pointed people to the IEblog, as that has some
of the best documentation I have seen on that topic.
-Jesper Kristensen
dbp
> Wed, 17 Aug 2011 21:22:58 -0700, /dbp/:
>
> > Facts:
>
> > 1. The life cycle of software development in business world is much
> > longer than 3 months. I would say 2 years as a fair time.
>
> The company I work for has a three weeks release cycle. It is
> essentially the same as with current Mozilla - we have two staging
> periods, like aurora and beta, and one roughly analogous to nightly.
> During these periods, features which could have been developed and
> tested for longer time prior that, get integrated and tested
> together prior release. We're using this process from the beginning
> (with small adjustments over time) and it is required to address the
> needs of fast evolving business.
>
> > to plan and be allocated.
>
> Yes, we plan on features which usually take longer than one release
> cycle to develop fully. Those features are developed and tested on
> separate environments prior "getting on the release train".
>
> > 3. Rapid release strategy introduced not only bug fixes and security
> > fixes, but feature enhancement. In other words, more bugs or chance
> > of incompatibility.
>
> As explained elsewhere, the rapid release strategy itself doesn't
> hurt the quality.
>
> Stanimir
More direct to say, IT people here has no resources to make the
software life cycle as fast as Firefox. IT people here will certainly
not bare the responsibility that a third party software update might
break the self developed one.
I was in development field for a very long time, touched mess code in
the field and great code in the open source world. I am certain that
even Firefox got issues, the team of Firefox will solve it in a couple
of days. What actually causing the problem are most likely the
extended features (say, in javascript core) caused some behavior
changes and then breaks the mess code.
dbp
>
> >> 2. The software development team are resources that need lengthy time
> >> to plan and be allocated.
>
> > Yes, we plan on features which usually take longer than one release
> > cycle to develop fully. Those features are developed and tested on
> > separate environments prior "getting on the release train".
>
> >> 3. Rapid release strategy introduced not only bug fixes and security
> >> fixes, but feature enhancement. In other words, more bugs or chance
> >> of incompatibility.
>
> > As explained elsewhere, the rapid release strategy itself doesn't hurt
> > the quality.
>
> And an important idea here is how we might work together to reduce that
> lengthy plannning and test time and spot compatibility problems earlier.
>
> How can you abstract test cases that identify key pieces of internal
> apps that you test over and over with each browser security and
> functional update?
>
> And how can we integrate test cases like that into our test suites so
> the planing and testing that you do now can be leveraged and shared by
> others?
>
> -chofmann
Test case is not the point of concern. For the IT systems here:
1. The software deployment team has internal assessment for a new
software (say, FF6), which would cause around 1 month of time
2. If the internal assessment past, it will ask other related parties
(say, website owners) to check and update the result, which would
cause another 1 month of time
3. If the website owners past the test, the software deployment team
will announce software upgrade to end-users, and then perform the
update, which would cause another 1 month of time
4. If the website owners object (say, it is incompatible to its site),
the deployment will be suspended.
In case of 4, the website owner may:
a. request for fix the bug, which more resources will be requested
b. request dropping support for FF6 but left only IE7/8/9
Wes Garland
>
>
> Test case is not the point of concern. For the IT systems here:
>
> 1. The software deployment team has internal assessment for a new
> software (say, FF6), which would cause around 1 month of time
> [...]
>
4. If the website owners object (say, it is incompatible to its site),
> the deployment will be suspended.
>
> In case of 4, the website owner may:
>
> a. request for fix the bug, which more resources will be requested
> b. request dropping support for FF6 but left only IE7/8/9
>
We use a different approach internally -- an approach which I believe is the
only responsible one in a world where web apps are used by the general
public -- and I believe must be adopted by intranet app developers, too:
1. We develop our products adhering as much as possible to established web
standards, avoiding newest features unless they are key to the application
2. We test our products on the latest version of Firefox, Chrome, and Safari
all through the development cycle. Some testing is also done on
Firefox-minefield, webkit-nightly, etc.
3. If a compatibility issue is found, we report it to the browser
manufacturer and MIGHT work around it. (Strangely, as long as you don't
care about pixel-perfect layout or bleeding-edge features, these are
incredibly rare)
4. Once the application is finished, we retrofit for whatever version of
Internet Explorer we have to support for whatever (corporate) reason.
Current plans are to not support anything older than IE9 for any products in
our current dev cycle.
5. Then we run the test suite on Opera. Have never had a problem with it
once the code worked on all the other browsers.
We have been roughly following this approach for a long time (Firefox 2),
with very few problems, and a Firefox update has never broken us. Even if
it did, if we were an intranet-app company, we could fall back to Safari
which ships with all our desktops, or Chrome, or something else. That's the
whole point of standards.
I believe the era picking a particular browser, and "certifying"
applications to run on it is long gone. Applications should be certified to
conform to standards. The days of rapid, web-breaking standards changes are
ancient history. We must build applications, both for the web and the
intranet, to run everywhere. My developers can do this. Yours can too.
Gervase Markham
> That is precisely the message we should be sending to those who will
> listen. "You can manage with our new model. It is possible." To those
> who respond with "no, absolutely not, you're no good for me" or "you
> must change in this way to accommodate me" though, I think it's
> reasonable to follow up with "you may be right. we may not be any good
> for you." and move on to trying to convince the next person.
But in this thread, that's not what you did. You didn't say Firefox was
not suitable "for your use case", you said it was not suitable "for most
enterprises".
But anyway, why not put it in the positive? "Using Firefox in the
enterprise does not work well with all software deployment models, but
Mozilla is committed to trying to help enterprises understand our
development processes and find a way of working compatible with them.
Join the EWG."
Gerv
Robert Kaiser
> But in this thread, that's not what you did. You didn't say Firefox was
> not suitable "for your use case", you said it was not suitable "for most
> enterprises".
There's at least one Enterprise in which the new process does fit:
http://home.kairo.at/blog/2011-06/new_firefox_process_in_the_enterprise ;-)
> But anyway, why not put it in the positive? "Using Firefox in the
> enterprise does not work well with all software deployment models, but
> Mozilla is committed to trying to help enterprises understand our
> development processes and find a way of working compatible with them.
> Join the EWG."
Yes, much better phrasing. Also, I'm not too fond of the "enterprise"
wording in the first place, as e.g. a large non-profit or a government
agency are not "enterprises" but probably have the same issues. I like
you mentioning "deployment models" as that's what it usually boils down
to. Companies who let people deploy their own software also don't have
that problem, I guess, but they might still be "enterprises".
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 should think about. And most of the
time, I even appreciate irony and fun! :)
Boris Zbarsky
> Den 21-08-2011 05:13, Boris Zbarsky skrev:
>> So I think that a page that doesn't browser-sniff and uses some basic
>> best practices (avoiding inline event handlers), works in all current
>> browsers, and actually passes Henri's HTML validator so that there are
>> no parsing gotchas should be pretty future-proof.
>
> Do we have an MDN article about writing future-proof websites? I don't
> think we have
I don't think we have either. I'll start a thread on .platform to
collect some ideas for such an article, then see if I can throw
something together, I guess...
-Boris
chris hofmann
>>
>> 1. The software deployment team has internal assessment for a new
>> software (say, FF6), which would cause around 1 month of time
>>
> 4. If the website owners object (say, it is incompatible to its site),
>> the deployment will be suspended.
>>
>> In case of 4, the website owner may:
>>
>> a. request for fix the bug, which more resources will be requested
>> b. request dropping support for FF6 but left only IE7/8/9
>>
Yes, I've talked to quite a few organizations that have adopted this model.
Some have even gone further, and they basically treat all their internal
applications
just like they treat there "external public customer facing apps." They
do some testing around the time of announced browser releases,
but mostly just react to any bugs that turn up in any new browser release
as they are reported by end users.
They instituted this kind of program based on cost analysis. They found it
much cheaper and more effective to just react on the very few cases where
where a browser releases create problems, than to spend lots of time and
energy in "pre-testing" browser releases, but not finding any problems.
dbp, do you have any metrics on the number of hours spend testing, and
the number or instances where this testing has been productive in
finding bugs?
Is it similar to Wes's experience that "a Firefox update has never
broken us" ?
-chofmann
chris hofmann
<snip>
>> And an important idea here is how we might work together to reduce that
>> lengthy plannning and test time and spot compatibility problems earlier.
>>
>> How can you abstract test cases that identify key pieces of internal
>> apps that you test over and over with each browser security and
>> functional update?
>>
>> And how can we integrate test cases like that into our test suites so
>> the planing and testing that you do now can be leveraged and shared by
>> others?
>>
>> -chofmann
> Test case is not the point of concern. For the IT systems here:
I don't understand this statement. Just about each of the points below
that you mention around assessments, checking, determination of
incompatibilities all involve testing.
My suggestion is that if you could add test cases to our automated
system the check key parts of your applications and sites, that would
enable you speed this process up dramatically and also tighten
up the methodology for approving new versions of browsers.
> 1. The software deployment team has internal assessment for a new
> software (say, FF6), which would cause around 1 month of time
> 2. If the internal assessment past, it will ask other related parties
> (say, website owners) to check and update the result, which would
> cause another 1 month of time
> 3. If the website owners past the test, the software deployment team
> will announce software upgrade to end-users, and then perform the
> update, which would cause another 1 month of time
> 4. If the website owners object (say, it is incompatible to its site),
> the deployment will be suspended.
>
> In case of 4, the website owner may:
>
> a. request for fix the bug, which more resources will be requested
> b. request dropping support for FF6 but left only IE7/8/9
> _______________________________________________
dbp
I attempt to give yet another message to the FF group that "the other
world is not working as you wish". But seems failed after dozens of
posts.
As a guy with long time of development background, I know what should
be a right approach. While not for the business men or clients
without technical background. What they see is just if the website
can be functioned and how much does it cost. What they cannot see is
how long this site can be sustained and how well it perform in
different browsers.
If you think they would get lessons being learned (to aware of
compromising to some standard), FF is the first to learn. I am sure
that the market share of FF will be dropped for a large portion in
business use within 1 year.
You may wish to have a look at the OS you are running (say, take Linux
as an example), are you upgrading all its components to the latest
version? I does not mean the RPM / PKG version but the latest stable
version from the developers, from kernel to web server to php and see
what would happen.
Wes Garland
> You may wish to have a look at the OS you are running (say, take Linux
> as an example), are you upgrading all its components to the latest
> version?
Thanks, dbp, this is a great example.
I write software which conforms to Single UNIX Specification v3 (~ POSIX).
Provided I stick to the specification, this software works without fail
across multiple vendors' Unix platforms; my two main deployment targets are
Solaris and Mac OS. Both of these OSes are certified UNIX-tm, and the
software runs properly on both platforms, without change, across multiple
versions. Even code which I wrote in the 1990s that conforms to POSIX
1003.1 still works. Heck, the SUSv3 code will usually run unchanged on
Linux/glibc, although there are sometimes issues because Linux does not
completely adhere to the specification (we also usually don't officially
support Linux).
So, yes, a development model where the source code is developed in
accordance with established specifications from a responsible standards
body (eg. The Austin Group, the W3C, ECMA, etc) has been shown through
decades of practice to be a practical way of writing software for the
enterprise.
Let's get web software development methodolgy up to the same standards!
Wayne Mery
> Yes, much better phrasing. Also, I'm not too fond of the "enterprise"
> wording in the first place, as e.g. a large non-profit or a government
> agency are not "enterprises" but probably have the same issues. I like
> you mentioning "deployment models" as that's what it usually boils down
> to. Companies who let people deploy their own software also don't have
> that problem, I guess, but they might still be "enterprises".
An enterprise need not be a for profit business. So I think it is fair
to use the term enterprise here in a larger sense, to include all
entities that use an application to further the goals of their entity in
supporting many users.
And, I think using deployment to define an enterprise is a mistake. I
would argue, enterprise issues are not limited to those entities that
purposefully deploy a mozilla app via some centralized model. Some have
a mixed model, where some users DL directly from mozilla and some use a
centrally deployed package. Others might require users to DL a mozilla
app directly from mozilla.
--
contribute ... http://wiki.mozilla.org/Thunderbird:Testing
evangelize Thunderbird ... http://www.spreadthunderbird.com/aff/165/
assistance with bugzilla/Thunderbird QA ...
http://www.mibbit.com/chat/?server=irc.mozilla.org&channel=#tb-qa
Chris Hofmann
> On 8/22/2011 9:30 AM, Robert Kaiser wrote:
>> Yes, much better phrasing. Also, I'm not too fond of the "enterprise"
>> wording in the first place, as e.g. a large non-profit or a government
>> agency are not "enterprises" but probably have the same issues. I like
>> you mentioning "deployment models" as that's what it usually boils down
>> to. Companies who let people deploy their own software also don't have
>> that problem, I guess, but they might still be "enterprises".
>
> An enterprise need not be a for profit business. So I think it is fair
> to use the term enterprise here in a larger sense, to include all
> entities that use an application to further the goals of their entity
> in supporting many users.
>
> And, I think using deployment to define an enterprise is a mistake. I
> would argue, enterprise issues are not limited to those entities that
> purposefully deploy a mozilla app via some centralized model. Some
> have a mixed model, where some users DL directly from mozilla and some
> use a centrally deployed package. Others might require users to DL a
> mozilla app directly from mozilla.
>
around "deployment of firefox in large organizations". I think that
helps get to the heart of the issue without bring along all kinds of
baggage.
As Kairo and Wayne suggest, nearly every large organization has a
different set of tools, different procedure, and different process for
deploying software. There is no one model and no one tool or change
that will uniformly solve deployment problems for every large organization.
It would be great to hear of more stories where large organizations out
there have solved these problems and have successfully deployed
Firefox. Its been hard in the past to get people to come forward with
this kind of information but we should keep trying.
-chofmann
Nicholas Nethercote
I vote for Wes as our spokesperson on all enterprise-related stuff.
Serious, the above email and the one earlier in the thread where he
discussed his web development processes are are two of the best things
I've read recently, adding some much-needed clarity to what's been a
very murky discussion about "the enterprise".
Nick
Wayne Mery
> I'll suggest using the term "large organization" and focus on the issues
> around "deployment of firefox in large organizations". I think that
> helps get to the heart of the issue without bring along all kinds of
> baggage.
Well, even a small organization can face the same issues.
--
contribute ... http://wiki.mozilla.org/Thunderbird:Testing
evangelize ... http://www.spreadthunderbird.com/aff/165/
QA assist ...
http://www.mibbit.com/chat/?server=irc.mozilla.org&channel=#tb-qa
Robert Strong
On 8/22/2011 11:25 AM, Chris Hofmann wrote:
> On 8/22/11 10:09 AM, Wayne Mery wrote:
>> On 8/22/2011 9:30 AM, Robert Kaiser wrote:
>>> Yes, much better phrasing. Also, I'm not too fond of the "enterprise"
>>> wording in the first place, as e.g. a large non-profit or a government
>>> agency are not "enterprises" but probably have the same issues. I like
>>> you mentioning "deployment models" as that's what it usually boils down
>>> to. Companies who let people deploy their own software also don't have
>>> that problem, I guess, but they might still be "enterprises".
>>
>> An enterprise need not be a for profit business. So I think it is
>> fair to use the term enterprise here in a larger sense, to include
>> all entities that use an application to further the goals of their
>> entity in supporting many users.
>>
>> And, I think using deployment to define an enterprise is a mistake. I
>> would argue, enterprise issues are not limited to those entities that
>> purposefully deploy a mozilla app via some centralized model. Some
>> have a mixed model, where some users DL directly from mozilla and
>> some use a centrally deployed package. Others might require users to
>> DL a mozilla app directly from mozilla.
>>
> I'll suggest using the term "large organization" and focus on the
> issues around "deployment of firefox in large organizations". I think
> that helps get to the heart of the issue without bring along all kinds
> of baggage.
or you could avoid the baggage by just calling it "Firefox deployment"
without any mention of enterprise, organization, etc.
--
Cheers,
Robert Strong
>
>
> As Kairo and Wayne suggest, nearly every large organization has a
> different set of tools, different procedure, and different process for
> deploying software. There is no one model and no one tool or change
> that will uniformly solve deployment problems for every large
> organization.
>
> It would be great to hear of more stories where large organizations
> out there have solved these problems and have successfully deployed
> Firefox. Its been hard in the past to get people to come forward with
> this kind of information but we should keep trying.
>
> -chofmann
Asa Dotzler
> or you could avoid the baggage by just calling it "Firefox deployment"
> without any mention of enterprise, organization, etc.
I like "managed deployments" or as you've suggested simply "Firefox
deployments".
- A
Asa Dotzler
> or you could avoid the baggage by just calling it "Firefox deployment"
> without any mention of enterprise, organization, etc.
I like "managed deployments" or as you've suggested simply "Firefox
deployments".
- A
Daniel Veditz
> No disagreement there. The rapid release cycle makes things more
> difficult (and sometimes impossible) for some managed deployments.
>
> This was the unfortunate trade-off we made in order to move
> Mozilla's organization and products to a cadence that would allow us
> to continue to lead the Web forward and to best advance our mission
> of building user sovereignty and a deeply compelling and competitive
> Web platform.
Mozilla made a choice but there's nothing magic about the Rapid
Release process that precludes a "limited support" release branch.
It takes effort to do, sure, but effort we've were already spending
on past branches. At the rate we're hiring we can't claim to be
resource poor. We can choose to deploy those people elsewhere for
reasons that seem good to us, but to imply it is a forced choice
forced by calling it a "trade-off" is a lie.
We answer to no one but the people willing to upgrade as fast as we
want them to.
-Dan Veditz
Asa Dotzler
It absolutely was (and is) a trade-off.
There's nothing magic about Rapid Releases except that it takes people
to do it. You're arguing that we can just hire more people and
everyone's happy but that argument is flawed. You are supposing that all
resources are fungible when they are clearly not. Yeah, we're hiring as
fast as we can, hundreds of people a year, even, but in a year of trying
to build a release management team, we've managed to hire approximately
zero people. Where's Christian's release management team? It doesn't
exist. It doesn't exist because we can't take any random hire and throw
them at release management. It is a specific set of skills and we're
having a somewhat difficult time finding good matches.
And it's Christian's team, at least a handful of new hires, that we were
counting on having in place by now when we moved to the rapid release
cadence. We need them because release management is actually
considerably more expensive with our rapid releases than it was in the
old system. We desperately need more resources in this area, and those
resources, the ones we probably won't finish hiring any time soon, are
already committed to the rapid release system and certainly can't just
be handed off to doing LTS.
So, yes, I think we can claim and should be honest about the fact that
we are very resource poor in certain areas. We're understaffed for the
work that Mozilla explicitly committed to when we began the move to a
rapid release cadence.
Hiring people with the skills to handle our release management workload
(excluding any LTS branch) has been difficult and we're nowhere near
where we need to be. Hiring for the kind of people that would be needed
to do the work of an LTS, a program we explicitly opted out of doing 8
months ago, would be equally difficult and would directly conflict with
putting those resources, could we get them, on the most important thing
they could be working on and the very thing we all committed to with the
move to the faster cadence. We need to fill up our gaps there and in
other places on the Mozilla project long before we start gifting our
limited resources to LTS.
So yes, it absolutely is about trade-offs. It is about making decisions
to do this thing and to not do some other thing. There is no lie and no
shame in acknowledging that to do some things well, with the resources
we have or can get in the near term, there are other things we cannot do
well or even do at all. This was fairly well understood when we decided
to move to rapid release and it was understood at the time that it was a
trade-off. We would be doing rapid releases and that would mean we could
not do LTS branches.
- A
Asa Dotzler
Dao
> Daniel Veditz wrote:
>> On 8/20/11 11:29 AM, Asa Dotzler wrote:
>>> No disagreement there. The rapid release cycle makes things more
>>> difficult (and sometimes impossible) for some managed deployments.
>>>
>>> This was the unfortunate trade-off we made in order to move
>>> Mozilla's organization and products to a cadence that would allow us
>>> to continue to lead the Web forward and to best advance our mission
>>> of building user sovereignty and a deeply compelling and competitive
>>> Web platform.
>>
>> Mozilla made a choice but there's nothing magic about the Rapid
>> Release process that precludes a "limited support" release branch.
>> It takes effort to do, sure, but effort we've were already spending
>> on past branches. At the rate we're hiring we can't claim to be
>> resource poor. We can choose to deploy those people elsewhere for
>> reasons that seem good to us, but to imply it is a forced choice
>> forced by calling it a "trade-off" is a lie.
>
>
> It absolutely was (and is) a trade-off.
If it's a trade-off, then it's a hypothetical one. We're still
maintaining Firefox 3.6. It's effectively on LTS.
Who's managing this? I think it's not Christian. dveditz?
Asa Dotzler
It was a trade off we signed up for that we haven't yet realized because
we changed our plans when enterprises erupted and decided to keep that
branch alive while we sort things out with enterprises.
That was not the plan. That's costing resources, fracturing our user
base, and not actually keeping those users very safe.
It was a trade-off that we were counting on, that is currently the
largest single failure in the move to rapid releases and it's a huge
problem that we need to kill as soon as humanly possible.
- A
Dao
Sure, it costs resources. Nobody said it didn't. What people (dveditz
and as far as I remember roc and bz) are saying is it costs resources we
can spend on it.
It does fracture our user base. In itself this isn't a problem, though.
It may have problematic implications, but I'm not sure what you have in
mind here. I have a hard time understanding how losing users that refuse
to keep up with rapid releases would be a net win.
As for "not actually keeping those users very safe", it needs to be
pointed out that 3.6 is older than a regular LTS branch would become.
Robert O'Callahan
> Sure, it costs resources. Nobody said it didn't. What people (dveditz and
> as far as I remember roc and bz) are saying is it costs resources we can
> spend on it.
>
It's a cost-benefit tradeoff, and my gut feeling (along with bz, I think)
and just about everyone in engineering I've talked to about this) is that
the cost is quite low and the benefit would justify it.
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]
Nicholas Nethercote
<rob...@ocallahan.org> wrote:
> On Fri, Aug 26, 2011 at 3:32 AM, Dao <d...@design-noir.de> wrote:
>
> It's a cost-benefit tradeoff, and my gut feeling (along with bz, I think)
> and just about everyone in engineering I've talked to about this) is that
> the cost is quite low and the benefit would justify it.
Just thinking out loud (hell, it's 4.45pm on a Friday here):
- Firefox 12 is due on April 23 next year. It's the 3rd 2012 release,
so we call it 12.3. Then we have 12.4, 12.5, etc, and the first
release in 2013 is 13.1. This should make everyone who has complained
about version numbers happy -- people calling for date-based numbers
get what they want, people who liked the old numbering system get
something close to what they want to (i.e. the difference between 12.3
and 12.4 sounds small in a way that the difference between 5 and 6
does not). And we can continue to de-emphasize the version number as
we have been doing (but maybe not going so far as removing it from the
About box :)
- A bigger change would be to introduce LTS releases, one per year.
The N.1 release would be an obvious candidate. The LTS release for
2012 would still be called FF10, because the switch to the date-based
numbering wouldn't have happened yet.
If our goal was to satisfy all external people who've been complaining
about rapid release, I think these two things would pretty much do it.
Of course there are some people within the community and MoCo who
wouldn't be happy about the LTS suggestion and the resources it would
tie up. But it would certainly be better than the pre-rapid release
model, because those who wanted rapid releases would still get them.
Nick
Jonas Sicking
<rob...@ocallahan.org> wrote:
> On Fri, Aug 26, 2011 at 3:32 AM, Dao <d...@design-noir.de> wrote:
>
>> as far as I remember roc and bz) are saying is it costs resources we can
>> spend on it.
>>
>
> and just about everyone in engineering I've talked to about this) is that
> the cost is quite low and the benefit would justify it.
For what it's worth I agree. Putting out a new long-time supported
release every 6 months should give people that want to more time to
verify before they upgrade, while still ensuring that we don't have to
back-port patches too far.
However we still need to put a lot of effort into making sure that Jet
Pack is a more viable option for addon developers so that lack of
addon compatibility isn't what holds people back to old releases.
/ Jonas
Gervase Markham
> - Firefox 12 is due on April 23 next year. It's the 3rd 2012 release,
> so we call it 12.3.
<bikeshed> If we are going to use dates, let's use dates. We are hitting
our release dates to the day (yay!) so we can predict them accuracy. The
April release should be 12.04. Like Ubuntu.
> If our goal was to satisfy all external people who've been complaining
> about rapid release, I think these two things would pretty much do it.
I think a 1-year LTS isn't very L :-), but it would help a lot of
people, and any longer means we'd start to lose the benefits of rapid
release. It's a good compromise.
Gerv
Steve Fink
> Just thinking out loud (hell, it's 4.45pm on a Friday here):
>
> release in 2013 is 13.1. This should make everyone who has complained
> about version numbers happy -- people calling for date-based numbers
> get what they want, people who liked the old numbering system get
> something close to what they want to (i.e. the difference between 12.3
> and 12.4 sounds small in a way that the difference between 5 and 6
> does not). And we can continue to de-emphasize the version number as
> we have been doing (but maybe not going so far as removing it from the
> About box :)
People will laugh at your shortsightedness in the year 3000. :)
If we really want to de-emphasize version numbers, we should just use
Roman numerals.
Of the hg revision.
ya knygar
> people, and any longer means we'd start to lose the benefits of rapid
> release. It's a good compromise.
i have proposed 9 days ago:
"- include 1 most popular in the month (oh, 3 weeks) add-one
in each release, or, even some of the labs feature to each new release.
Why not? are other - "closed room" - decisions are better than what people vote
up for real?
other way
i propose - get rid of the importance of the version number since it
is "unimportant"
to "end-users" at least - currently. Provide the smooth updating(i
have suggested some useful
UXfixes)
after each bug and let it be.
Maybe - leave the Firefox (ain't Firefox is a too personal name,
for a stated "personification for user" politics?) naming at all,
aren't there people who doesn't really like foxes, or hate them,
why disrespect them? Are there many people like foxes? or fire?
i'm just curious of statistics..maybe somebody could kindly argue for me.)
Maybe -
Call it Mozilla, call every new feature by the name of some dead
species of animals or plants
(resembling the "dead" dino of the Main Logo that kind of alive and
named Mozilla, maybe plants would
be cooler - stating their Mozilla is a vegetarian and still - very
mighty, One Of a Kind as i say)
Be cool.
Personally - i feel bad for Firefox 6,10,11
it reminds me the animals that being tortured
in one-way space ships and kinds:)
Am i the only one?
For corporations and other people which can't offer an instant updating
- there should another case"
As for corporate - i was proposed a build,
kind of LTS with a specific func. like "Sync Corporate" etc.
Some - very tiny ERP-like system that would just fit right into
big corporations maintaining. Including the back-ports XULRunners,
Prism's, whatever was broken for someone.
By thins - i think Mozilla could stay cool and be cool for corporations,
that is also important as you see. The expenses shouldn't be so big
but there are - certainly a benefits a Build - that could be done for
corporations.
that time - when i was proposing on this versions battle-field - i
haven't received feedback,
so - i was "the only one", obviously )
Now - when the LTS and "Like Ubuntu"
is being mentioned - maybe this kind propositions would
have another chance?
PS:
I don't care for corporations actually, but i do care for educational,
government, institutional fields,
and - I just like the Mozilla and have seen enough disasters - being
done by outdated corporate browsers,
especially on certain OS platforms.
Blake Kaplan
> I think a 1-year LTS isn't very L :-), but it would help a lot of
> people, and any longer means we'd start to lose the benefits of rapid
> release. It's a good compromise.
For what it's worth, from my point of view, 1 year is extremely L. With every
change that goes into a section of code, potentially-backportable patches
become less relevant to the old branches. Depending on exactly how much work
went into the area in question, even 3 months of churn could mean that security
patches have to be entirely rewritten across branches.
--
Blake Kaplan
Nicholas Nethercote
> Gervase Markham <ge...@mozilla.org> wrote:
>> I think a 1-year LTS isn't very L :-), but it would help a lot of
>> people, and any longer means we'd start to lose the benefits of rapid
>> release. It's a good compromise.
>
> For what it's worth, from my point of view, 1 year is extremely L.
Of all the commentary I've read, I can't recall anyone who wanted an
LTS release who wanted more than 1 year. (BTW, I'm not claiming it
would satisfy 100% of people asking for an LTS release, but I suspect
it would satisfy 98% of them.)
Nick
Gervase Markham
> For what it's worth, from my point of view, 1 year is extremely L. With every
> change that goes into a section of code, potentially-backportable patches
> become less relevant to the old branches. Depending on exactly how much work
> went into the area in question, even 3 months of churn could mean that security
> patches have to be entirely rewritten across branches.
Right - that's the compromise. Looking at software across the industry,
1 year isn't very L (one competitor of ours does > 10 years) - but for
our developers, one year seems pretty L, and any more would be even more
painful.
I hope the EWG will give us data on whether 1 year would actually help,
or whether all the groups who want > 3 months wouldn't be satisfied with
anything less than e.g. 5 years. If that's so, then it wouldn't be worth
doing.
Gerv
Robert O'Callahan
just ones that are publicly known (or judged likely to become so).
ya knygar
@Gerv,
i'm sure that other participants have thought about
of almost all that usually comes up in Moz lists,
> It is also important to speak from a position of knowledge and
> understanding. Mozilla has more than enough people who are able to say
> "I would like this..." without any understanding of whether it's
> possible or considering the trade-offs involved.
i don't see anything impossible for Mozilla Community,
however i do see much of unrealized potential by Mozilla Corporation.
I'm considering trade-offs ofc., i always try to,
saying "without any understanding"
i think - should not relate to any person from Mozilla Community.
Who bother to waste the time in constant begging for changes,
not only - resolving the bugs.
I don't know much about inland Mozilla of today,
but i'm using Your product along with all other major browsers on
all major platforms - since 1st version and before (remember Firebird,
Netscape, remember the joy from the next new splash screen:)
for many years - so - i have a
grown opinion. Also - i have a considerable memory on changes and UX,
that's my profession.
what i'm proposing actually - is to - Change the Style,
of Mozilla main Product - before it is too late.
Why it is important now and why it was like "ok" before?
I'll explain very briefly, because i don't want to waste time here - again:
1. New version of Firefox - increasingly means - new article in press,
users expectation for changes. It isn't like before, it isn't like in Chrome.
> - include 1 most popular in the month (oh, 3 weeks) add-one
> in each release, or, even some of the labs feature to each new release.
What you have now?
Despite the angry corps sys-admins,
Mozilla have some hundreds of millions of home users,
I don't actually know - how many people using Add-ons - in general,
just know what i'v seen among my friends, mates, businesses.
All are in Ukraine/Russia.
So - i suggest you have stats etc.
You know that people kind of liked Add-ons idea and kind of
using them and love certain Firefox Add-ons.
What i see here, actually? Most of the people - doesn't know or use
the Add-on's (well, besides the Yandex bar, they hate it but often - too
lasy to switch of after reinstall or something, oh yes - sometimes it is(was)
better to reinstall FF).
At least - not a part of these thousands.
So -- Mozilla have the major expectations that it can't fulfill for a few latest
versions, so - when people look for - Wow, you introduce them a grey letters
in address bar as an awesome bar and, well, WebSockets?
See - there are some cool Labs Add-ons, experiments, some simply - cool Add-ons
that majority would never see (probably, who knows, anyway),
What I See - if you'd focus on performance issues rather than on adding some
new UX features that sees like in alpha state -- would be better for people.
BUT - It is Firefox 7! it should be New, Better - that's what many of
your users think and write about.
By "New" and "Better" they often mean - new - better UX or Wow effect
from something.
What i propose? I propose to Add the Wow effect by some Featured
Add-on in any new Version.
By that - stimulating disappointed Add-on developers, by that -
showing the Wow and New effect
for UX and Performance/Standards improvements for Browser.
OFC. you could propose to turn off the Add-on on first start of new
version, leaving all
like in FF4 or, even - back to FF3 style if user wishes.
What i see also -- HQ of Mozilla says and increasingly moves to
Customizable User eXperience,
What it would mean finally? It would mean that all your UI changes -
including tabbed menu, icons,
bars, -- all wouldn't mean much - some time soon. What i hear from
Mozilla? Asa replies
"ya knygar wrote:
What I mean exactly - is a future - where people could receive
exactly what
they need by a combined add-ons+themes+persona affords
This is in the roadmap for Firefox. The UX team gave a public
presentation on just such a feature two weeks ago. You may be able to
find more participation on this kind of topic in the UX or Firefox
lists rather than the mozilla dev planning list."
Wow, that's what i mean, thank you. That would finally lead to
situation with variants:
A. variant - Firefox would turn into a kind of Chrome by mean of new
releases doesn't mean
and what is more important - expected to mean - anything for UX.
B. variant - you would still try to amaze the users that use Mozilla
for Joy, not only Work.
(for these who Work with it - you see the result of changing 3rd UX to
4th, no, really,
corps people - angry not just because of broken Apps)
Other sides for 1.? Ok, - what's about Firefox - being so personable
now - still is a person itself,
Fox changing personas, fox changing themes, fox with add-on's.
Really - are there any statistics Mozilla HQ know about - how people
feel of foxes nowadays?
Would they like to associate themselves with foxes in a future?
I could write an article or two, but for what, what i'm saying should
be really obvious for people who work in Mozilla Corp,
ain't it?
-
ok, that was 1. explanation of my words -- about the Featured Add-ons
for Wow and other benefits, now comes the second
variant i see
-
2.
> Maybe -
> Call it Mozilla, call every new feature by the name of some dead
> species of animals or plants
> (resembling the "dead" dino of the Main Logo that kind of alive and
> named Mozilla, maybe plants would
> be cooler - stating their Mozilla is a vegetarian and still - very
> mighty, One Of a Kind as i say)
"One Of a Kind" means - Mozilla is the only major Open Source browser
that kind of saving the Web for a while, still - it is just another
"Free Download"
for majority of users, that majority doesn't know nothing about Fully
Open Source,
of Free software that Mozilla encourages (despite the controversial
GNU/MPL discussions,
personally - for my project i'v encouraged the early adoption of MPL2,
because i see it
as a great license that could change some more things for FLOSS, but
that is another story)
So - i see the Huge Fail with marketing, i'v described a bit of my thoughts -
https://groups.google.com/group/mozilla-labs/browse_thread/thread/a6b6689845bf2dff/de5a64cb8b2fabbe?lnk=gst&q=webfwd#de5a64cb8b2fabbe
since than - a situation is changed even more.
i see the relation of that Fail and overall effect of aging in the
Brand of Firefox.
As for me - whole
https://secure.wikimedia.org/wikipedia/en/wiki/History_of_Mozilla_Firefox#Naming
story is about a bad choices for Branding. I have a strong opinion
that the power of Mozilla.
So - to sum up - Mozilla is constantly failing and i am, as for now,
don't use the Firefox at all,
i'm using IceCat and Aurora, not because i don't like the foxes
but because i can't or i wasn't able to use latest dev release of
Gecko along with Firefox,
On Mac - i don't use Firefox because
of ugly UI design(yes, i know - i could change it with some afford,
but why should i care if it brakes all the Mac UX)
On Windows i don't use it mainly because - i don't use Windows, but if
i would - i would still prefer some Pale Moon,
because of, well, i don't like the big default orange sys-tab along
with whole Orangeness that i'v head enough from Mozilla
during these years (to add - i constantly preferred to use the default
"theme" for Firefox, as i kind of used to that - it runs faster)
> Call it Mozilla
since People i know - generally heard that FF is Mozilla (Fox is
Dino's, oh, well)
Mozilla won't lost its name if you'll get away from "Firefox"
> call every new feature by the name of some dead
> species of animals or plants
it, as a !variant that could help the smooth transition from some
Mozilla Firefox 12
to some Mozilla codename XYZ for example Mozilla: Salvinia natans,
when
oh.. yeah, that is strange and you should use the Firefox for Browser
and Thunderbird for Mail,
years after years in the era of customizable UX. (don't know any
people who doesn't try or like
the UI customization of their OS, besides the OSX users that just
aren't do it in a right way,
as i know :)
it could be just a respectful codenames for major releases, and for
small there would be
small numbers - that - people doesn't care about. Like Chrome, kind of Ubuntu.
It is for an A. variant - where numbers doesn't mean so much, it is
for A. variant -
where UX and UI is a matter of Users, not - orange fox.
If there would be another naming - just a codenaming for a major
releases -- people would just lost and won't find "the discussions
about" and bug-tracking would be broken.. or not?
@Gerv, you know more about Bug-tracking, could you comment?
Are the current - new version in a 3 weeks - helps to see - if there are
resolved bugs in a new Version for user?
Moreover - is that conception i explain - is really strange in the
current world?
Isn't - "be/support Green" if any, is more important for customers
than be "FireFox"?
Does Fox should be so appropriate for a user-identification because it
is a kind of tricky werewolf, still the pretty rude being?
People are increasingly spending their lives in Web, In Exploring in
Safaring, in Chrome..
...in FireFox'ing?
> Personally - i feel bad for Firefox 6,10,11
> it reminds me the animals that being tortured
> in one-way space ships and kinds:)
i'v asked the friends - they feel the kinds of same.
If variant that being pushed by Mozilla HQ is A.
by this - numbers doesn't matter much for end-users --
then - why to release and promote it all as Firefox "7",
"wow, that's should be something new"
If variant is B. and you try to introduce something new (not
by Add-ons, i realize that my sweet dream probably is too radical
for todays Mozilla HQ)
--why are you - urging yourself and trying to beat the Time with
stated 3 weeks circle,
if you clearly see - that 3 weeks isn't enough to beat the bugs,
not about - introduce something Wow from Mozilla Team..?
-
i have 3. and 4. and 5. in mind - but i'd better not post as, maybe
you know it all 100hundreds times and still - have a Big Secret Plan
about Mozilla's future so - all the people who constantly proposes changes
for Mozilla - just waste their time (and better if they'll just fill
another Bug).
All is written from HQ heads, isn't it?
If it isn't so Big and Secret - so there are
https://wiki.mozilla.org/Firefox/Roadmap
and there are small "Put the user in control
Fully customizable"
does this correlate with what you currently see during these weeks?
Doesn't that - "Put the user in control" is NOT in the WAY
of "No plans to change the version number scheme"
..
after all these hundreds of posts and messages?
doesn't it seems wrong at all? is it a normal process?
PS:
>Perhaps English is not your first language?
yes,
> making your messages short
i can't, if i would it would be like -
Dear Mozilla!:
*change the name - because it isn't appropriate
- for the current versions scheme
- for experience of users
- for haters of foxes
- for haters of orange
- hm, etc.
*change the style - because it isn't appropriate
- for the current versions scheme
- for experience of users
- for haters of foxes
- for haters of orange
- hm, etc.
..
i don't think - in a that way - you'd understand or listen to.
As for Big Messages, this message isn't big as for me
and people which don't like it could skip it anyway,
the best i could hope for - some "Yes, no, too much text, too loose
argumentation"
even such a feedback is better than nothing,
but - if i'd get it anyway (seems like people getting it anyway like
this on Moz lists) --
why not try to describe to some rare person which could overcome my
English syntax
and could be interested.
Dao
> On Fri, Aug 26, 2011 at 3:32 AM, Dao<d...@design-noir.de> wrote:
>
>> Sure, it costs resources. Nobody said it didn't. What people (dveditz and
>> as far as I remember roc and bz) are saying is it costs resources we can
>> spend on it.
>>
>
> It's a cost-benefit tradeoff, and my gut feeling (along with bz, I think)
> and just about everyone in engineering I've talked to about this) is that
> the cost is quite low and the benefit would justify it.
I suppose you mean benefit as far as the Mozilla mission is concerned. I
consider this the most relevant aspect, but I'll add that even in the
stricter economic sense there's not just a negative side. According to
Asa, 'the entire global "knowledge worker" segment (people with desks
and computers) is between 200-300M users.' I think chofmann said we had
about 20% market share there. How much revenue do these users generate?
Ron Hunter
That would be hard to quantify since many corporate IT activities
restrict access to the internet. Some quite closely. This will tend to
stifle revenue streams accessible to Mozilla.
Chris Hofmann
Expecting an "answer" on a question like this seems pretty optimistic to me.
As mentioned previously in this thread, and others, large institutions have
a wide variety of "requirements", tools, and process for the way thay manage
software.
What we can say is that Firefox has been on about a 1 year (maybe slightly
longer) life cycle over the last several years, and during that time
adoption
in the enterprise has roughly followed the rate of adoption in consumer
marketshare measurements. That would be an indication that a 1 year
cycle is actually working for many organizations.
-chofmann
> Gerv
Dao
I don't know where Asa got his numbers from, but they might miss users
without internet access anyway. As long as internet access isn't
completely locked down (i.e. the search bar works), those users should
be generating revenue.