How conservative platform and innovative browser could exist in parallel
Kai Engert
Being innovative or being conservative.
The web surfers, the marketing, the press, they want the hype and they
want innovation, fast.
The business users want a conservative platform they can build their
applications on, that they can certify for compliance etc., and which
they can rely on to be usable and secure.
Our non-IT-geek parents, who can't deal with constantly changing UI
every 6 weeks without getting some training from their kids, even they
require a conservative browser, too. We, their kids, cannot educate our
parents every 6 weeks. (Where's the padlock? Where's the statusbar? My
browser looks different than yesterday, is that a virus?)
So, what's our mission? Are we trying to be a browser for most people,
or do we focus on the hype? I hope we won't abandon one for the other.
Mozilla Firefox is a great piece of technology for two reasons. It's not
just a cool and secure browser. It's also a great platform. Applications
have been built on top of our standards based platform, and the
developers of those applications got our security fixes for free.
Yes, that was a free lunch for those developers. But on the other hand,
it brought more users to our platform that is based on open standards.
It brought us influence. And influence towards the good is the idea of
the Mozilla manifesto.
If we take away the benefit of security fixes from those areas, those
areas might begin to switch to different platforms, and Mozilla might
loose the influence that it had carefully developed over the years.
In my opinion, it could work like this (which is similar to the proposed
enterprise or LTS versions, but proposes a different numbering for
clarification):
Firefox 6 (or "even" major numbers) is conservative. It will be
maintained for one year (and optionally maintained longer by non-Mozilla
groups who want to help). There might an update every weeks, or less
frequently. Only security and important correctness fixes, just like in
the past.
Firefox 7 (or odd major numbers) is the innovative release. Every 6
weeks, there will be a 7.1, then 7.2, etc. The developers will try to
notice important correctness fixes and propose them for the conservative
branch.
One year after Firefox 6, instead of Firefox 7.9, we would release
Firefox 8, the new conservative release.
Everyone would be able to make their own decision, either conservative
or innovative. Those staying with "even", will get only security fixes
for a year. Those going to "odd" will get the new innotivations every 6
weeks.
If Mozilla doesn't want to maintain the conservative versions on their
own (contrary to what Mozilla in the past), then Mozilla should at least
provide the infrastructure, and coordinate the business world to make
these conversative maintained versions possible. (See also my other
recent proposal how a quick developer questionnaire might help to make
this less work.) Mozilla could also see this as an experiment, how many
contributions we get here. Given how many people demand a stable
version, I believe this experiment would be worthwile.
With this scheme, businesses could build their applications on top of
the conservative versions.
With this approach, we enable deployments to ship a conservative
platform in parallel to the innotivate browser.
Depending on the environment's needs, either the conservative or the
innovative browser can be shipped.
Kai
beltzner
As mentioned elsewhere (and really, I'm terrified of the fact we now
have about 6 different threads carrying on the same conversation in
this newsgroup :/) there's a lot of confusion about requirements vs.
resources.
In the past - and I speak from my experiences as a former product
manager for Firefox, here - Mozilla attempted to balance the
requirements of innovation with those of organizations that required a
longer support cycle. The goal was always to do the best possible
thing for the largest amount of users on the web.
Back when we were shipping Firefox 2 and Firefox 3, the Mozilla
platform was the most modern and fully capable web rendering platform
available. We were leading both in technology development and in
delivery time to market. Supporting older version of Firefox was
important as it provided an "on-ramp" that brought more users into a
modern Web technology era, which then would influence web developers
to take advantage of that technology.
After Firefox 3 shipped, an explosion of web technology development
occured. Mozilla, Google and Apple all began aggressively developing
web technologies, and web developers began using them more quickly. Of
those three providers, only Mozilla spent time providing full security
and stability support to older releases. It quickly became apparent
that we were being squeezed for resources on both sides: we had to
move faster to keep up a leadership position in new technology
development, but also spend a great deal of time and energy on
maintaining support for older releases. Our collaborators/competitors
with many more resources than us did not accrue these costs.
> If Mozilla doesn't want to maintain the conservative versions on their own
> (contrary to what Mozilla in the past), then Mozilla should at least provide
> the infrastructure, and coordinate the business world to make these
A pleasant idea, but one that overlooks the cost of that co-ordination
and infrastructure on our ability to produce new technology, and also
assumes that these people will come out of the woodwork. I do not know
of anyone who is willing or capable to do this - do you?
> we get here. Given how many people demand a stable version, I believe this
> experiment would be worthwile.
I have yet to see the evidence. We see a lot of people demanding it,
because Microsoft provides it for free. As long as I have been
involved with Mozilla it has been a hope that someone would step from
the shadows and provide a third-party, for-pay solution to this issue.
A few existed back in 2005, but they've all faded away.
Ultimately the source is open, the code is free, and there's nothing
stopping someone from eating our lunch in this space if indeed we are
letting it sit and get cold on a plate. I'm not sure that Mozilla
needs to do anything here, especially, other than make it clear that
they're willing to provide guidance and help for someone looking to
get started. That goes back to messaging, though, rather than
investment. I thus wonder if this shouldn't become part of the
Developer Engagement bailiwick.
cheers,
mike
Boris Zbarsky
> Our non-IT-geek parents, who can't deal with constantly changing UI
There's an important distinction being glossed over here.
The development pace for UI changes and web-facing code need not be the
same. Moving fast with web-facing features does NOT require changing
the UI significantly every 6 weeks.
And as far as I can tell, the UI hasn't changed significantly from Fx4
to Fx5, right?
> So, what's our mission? Are we trying to be a browser for most people,
> or do we focus on the hype? I hope we won't abandon one for the other.
I don't think those are mutually exclusive things.
In particular, I think the "non-IT-geek" parents can do OK (modulo
extension issues) with the current release setup.
-Boris
Dao
> Our non-IT-geek parents, who can't deal with constantly changing UI
> every 6 weeks without getting some training from their kids, even they
> require a conservative browser, too. We, their kids, cannot educate our
> parents every 6 weeks. (Where's the padlock? Where's the statusbar? My
> browser looks different than yesterday, is that a virus?)
Pasting my comment that I already made elsewhere:
Even a LTS release won't be supported *forever*, and when support ends,
you'd face [...] significant UI changes from one LTS release to the
other. On the other hand, if you follow the rapid releases, you'll have
only a small set of UI updates with each release, which users will
likely be able to handle without retraining.
Asa Dotzler
> The ongoing discussions show two divergent requirements:
> Being innovative or being conservative.
>
> The web surfers, the marketing, the press, they want the hype and they
> want innovation, fast.
It's not just those groups you list. It's every public Web app team out
there. Facebook wants innovation. Google wants innovation. Zoho wants
innovation. Microsoft wants innovation. JS toolkit developers want
innovation. Half the startups on techcrunch want innovation. All of them
want it and they want it fast.
Your attempt to isolate "businesses" as conservative and incapable of
keeping up with rapid change ignores the tens of thousands of businesses
on the Web that are and have been keeping up with rapid change because
they use Web standards and we try really really hard not to break those
people with each update.
> The business users want a conservative platform they can build their
> applications on, that they can certify for compliance etc., and which
> they can rely on to be usable and secure.
You mean system administrators working for companies with Intranet
applications that are not written or maintained by highly competent Web
developers here, I believe. Because Google is a business that builds
applications that they can rely on to be usable and secure across a half
dozen browser vendors and a couple of dozen versions which are updating
many times a year.
> Our non-IT-geek parents, who can't deal with constantly changing UI
> every 6 weeks without getting some training from their kids, even they
> require a conservative browser, too. We, their kids, cannot educate our
> parents every 6 weeks. (Where's the padlock? Where's the statusbar? My
> browser looks different than yesterday, is that a virus?)
The UI changes are more gradual and smooth in a 6 weeks delivery cycle
than in a 2 year cycle. Gradual change is much easier to adapt to than
major change over long periods of time.
> So, what's our mission? Are we trying to be a browser for most people,
> or do we focus on the hype? I hope we won't abandon one for the other.
Your characterization of "pretty much everyone on the public web" as
"the hype" I think is unfair.
- A
Henri Sivonen
> Ultimately the source is open, the code is free, and there's nothing
> stopping someone from eating our lunch in this space if indeed we are
> letting it sit and get cold on a plate.
I think what's stopping someone from providing the service using the
open code is the same reason you gave earlier for why MoCo is
resource-constrained in this area: To provide proper security support,
the abilities of the MoCo super-reviewers who really know the code well
are needed. If a third party could do it on their own, so could a
separate maintenance team at MoCo.
> I'm not sure that Mozilla
> needs to do anything here, especially, other than make it clear that
> they're willing to provide guidance and help for someone looking to
> get started. That goes back to messaging, though, rather than
> investment.
Though now that the messaging situation is along the lines of
http://www.pcmag.com/article2/0,2817,2387514,00.asp?f=2 can the
situation be fixed by messaging alone without accompanying it with some
technical changes to show that new messaging is for real?
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Axel Hecht
there is.
In my Nightly, the blink and the marquee tag still work. Like, the
*marquee* tag. Yikes.
There's really not a lot of things on the web that cease existence.
And today, with DOM0 being defined by html5 and all web vendors being
committed to actually work towards that spec, the foundation to build
your web on is more stable and conservative than ever before.
Of course, we offer new things, and those things may be in flux. But
nobody's forced to use them.
... which probably hints at us fostering a community that exchanges best
practices around how to build contracts for web work that's supposed to
live on the conservative side. We learn a lot about that with the
contracting we do ourselves these days, so we can also participate in
that discussion. Include testing and documentation requirements.
Axel
Am 27.06.11 16:30, schrieb Kai Engert:
Gervase Markham
> On Mon, 2011-06-27 at 10:45 -0400, beltzner wrote:
>> Ultimately the source is open, the code is free, and there's nothing
>> stopping someone from eating our lunch in this space if indeed we are
>> letting it sit and get cold on a plate.
>
> I think what's stopping someone from providing the service using the
> open code is the same reason you gave earlier for why MoCo is
> resource-constrained in this area: To provide proper security support,
> the abilities of the MoCo super-reviewers who really know the code well
> are needed. If a third party could do it on their own, so could a
> separate maintenance team at MoCo.
That, and also perhaps the business uncertainty. If they put substantial
investment into hiring and ramping up engineers, setting up build
systems, and providing delivery, do they know that in 12 months time we
aren't going to change our mind, decide that actually the enterprise is
important, and start competing with them?
If we are going down this path, the best thing we can do is burn our
bridges.
And if they do a good job of it, would we let them call it "Firefox"? Or
"Firefox Enterprise Edition"? Or anything with the word Firefox in?
Gerv
beltzner
> And if they do a good job of it, would we let them call it "Firefox"? Or
> "Firefox Enterprise Edition"? Or anything with the word Firefox in?
Kev (currently on holiday) and Harvey have some pretty good guidelines
about what gets the brand vs. not. Really depends on what they enable
and what sort of security update policy they maintain, I think. It's a
good question to work through, but I wouldn't spend a bunch of time
with it until you had a serious group of people looking to make good
on the production side.
cheers,
mike
Kai Engert
> Of course, we offer new things, and those things may be in flux. But
> nobody's forced to use them.
Unless I misunderstand, if you want security fixes, you are forced to
use the new things.
Kai
Mike Shaver
> On 28.06.2011 12:50, Axel Hecht wrote:
>>
>> nobody's forced to use them.
>
> the new things.
No, you have to take the new builds. Most of the new things are new
content features, which means that intranet apps are free to take
advantage of them or not. Some of them (HTML5 parser, JS engine
upgrades, UI changes) are more mandatory, though during transitional
periods we've had prefs to disable some of the new capabilities.
UI changes will necessarily tend to be more incremental between
releases than they have been in the past both because the cycle time
is shorter and because of the policy that they need to have a
disabling mechanism in case of late-breaking issues. That should make
user adaptation easier, according to everything I understand about
humans and change.
Mike
Ron Hunter
What features you use, or don't use is entirely up to YOU.
Kai Engert
>> So, what's our mission? Are we trying to be a browser for most people,
>> or do we focus on the hype? I hope we won't abandon one for the other.
>
> Your characterization of "pretty much everyone on the public web" as
> "the hype" I think is unfair.
I apologize if the word "hype" is interpreted negative, I didn't intend
to be negative. Innovation is good.
My point was to distinguish between people capable of dealing with rapid
change, and those who require assisantance to adopt (will require
assistance/training more often), or environments who require a tech
department to verify internal compatibility prior to rolling out a new
release (will have to repeat this testing cycle more often, in order to
stay up to date with security fixes).
Kai
Mike Shaver
> My point was to distinguish between people capable of dealing with rapid
> change, and those who require assisantance to adopt (will require
> assistance/training more often), or environments who require a tech
> department to verify internal compatibility prior to rolling out a new
> release (will have to repeat this testing cycle more often, in order to stay
> up to date with security fixes).
Right, there are two kinds of organizations with Firefox running
inside them right now:
* organizations which permit Firefox, but don't roll it out org-wide
* organizations which deploy Firefox as part of an org-wide software
management system
The former are not affected by what you describe, in that they neither
need IT permission nor IT assistance to update their Firefox (and
indeed have likely been updating right through out-of-process plugins
and similar quite happily).
The latter are an interesting case, especially since we have heard
that enterprises need MSI and GPO and such to do deployments. So
we're talking about orgs with bespoke handling for Firefox, which
leads me to believe that they might be also able to adapt to a
faster-but-smaller-changeset release cycle. Unfortunately, we're
unlikely to hear from many organizations that can handle this just
fine, since it's a non-issue for them!
But we shouldn't pretend or portray that all enterprises are in the
second ("IT managed") category, and that all in the second category
are unable or unwilling to adapt. Some of those in the second
category in fact do manage to use Chrome's MSI/GPO to roll out in
their enterprises.
I have access to IT staff at a school with ~3,000 employees and
~100,000 students, so I'll see what I can get them to tell me.
They've rolled out Firefox already, so they'll have some useful
experience to share as well.
Can you reach organizations that you've had experience with and see
what they think as well? We're probably not going to get to a
representative sample of current and prospective deployments, but more
data is unlikely to hurt.
Mike
chris hofmann
In deed, the landscape for what everyone is classifying as 'Enterprise'
in the active threads on this topic is much more complex that one or
two categories. There are all kinds of reasons and processes used to
deploy Firefox. We have very little data on this. What data we do have
suggests that Firefox adoption and marketshare in 'Enterprise/Business'
is a mirror of what it is in the 'consumer' market.
https://wiki.mozilla.org/Deployment:Deploying_Firefox#Marketshare_in_the_Enterprise_and_Business
The Forester and other studies referenced there are from 2010, so if
anyone has seen
updates it would be good to add. The bottom line is that there is
significant
institutional adoption without MSI's, lots of feature work targeted at
enterprise,
or any of the other side topics being discussed in these recent threads.
These institutions made the decision to deploy firefox for largely the same
reasons individual users start using firefox.
To demonstrate how all-over-the-map 'Enterprises' are
I know of one Wall Street Financial services organization with 30,000 seats
deployed that has abandoned the 'test before deployment' methods they
used in the past.
The have turned on regular Firefox updates from Mozilla
and they treat their internal web applications just like they treat their
external web applications. If a new browser release breaks them,
they get feedback from users, and they go in and make adjustments
to fix it. They analyzed the costs spent in IT resources to pre-test,
and do custom roll-outs versus the value they were getting and decided
to change to this new model based on higher value. One of the questions
they asked me in doing this evaluation is "How many times per year do
security updates create broken browser releases with serious problems
that require respins. Our track record for this is about 1-2 per year
going back as far as 2005. The response to this data was "once or
twice per year I can live with, and more than that will be a problem"
Yeah, this is a pretty enlightened position to be taking, but it also
reflects how institutional use is changing as IT departments are
downsized, and the percentage of workers in large corporations
shifts to smaller and more mobile and agile businesses.
To me that is really the question. Do we have things in place to
continue producing high quality releases with minimal bustage?
We are still light on Aurora and Beta test populations. If we can't
grow those to the million aurora and ten million beta users scoped in
the original rapid release plan we are going to have the adjust the
length of the development cycle. We need to stay focused on
efforts to rapidly gather digest user feedback from these testers
with improvements to crash-stats, input, telemetry, and other
sources.
Even then we may have to adjust the length of the cycle for some changes
that really deserve a larger and longer test cycle. Bug 656120 is probably
the first example of many that will come with needs for bigger testing
populations and longer or multiple test cycles. Changes that cause
the new code to be run in non-deterministic ways with a variety of
subtle and hard to describe impacts from a users prespective all
fall into this category. All of the electrolysis work is another example.
There were just too many areas in the Firefox 5 release we were flying
blind with a lot of uncertainty about the quality of the release due to the
low user populations. Getting to 4 million beta testers for Firefox 4
removed a lot of uncertainty.
This focus on high quality applies to both 'consumers' and
'institutions' that have already deployed Firefox
in significant numbers, in a wide variety of industries from
Financial Services, to Technology (IBM and others), to Aerospace,
to Governments, to Manufacturing...
Keeping quality high is really the key to all this, and there needs to
be more discussion on how we will do that. That's the way we
will hang on to all the individual and institutional users that we have,
and continue to grow both pools.
-chofmann
> Mike
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Mike Hoye
> On Tue, Jun 28, 2011 at 9:46 AM, Kai Engert<ka...@kuix.de> wrote:
>> My point was to distinguish between people capable of dealing with rapid
>> change, and those who require assisantance to adopt (will require
>> assistance/training more often), or environments who require a tech
>> department to verify internal compatibility prior to rolling out a new
>> release (will have to repeat this testing cycle more often, in order to stay
>> up to date with security fixes).
> Right, there are two kinds of organizations with Firefox running
> inside them right now:
> * organizations which permit Firefox, but don't roll it out org-wide
> * organizations which deploy Firefox as part of an org-wide software
> management system
There's a third and surprisingly common category; organizations that
increasingly require a modern browser for some segment of their
employees to do their job, but don't officially deploy or manage it. In
a number of companies I've spoken to, particularly those in areas bound
by data management laws and software accounting practices, IT managers
acknowledge that it's a problem they know about, but struggle to
officially address. Unsurprisingly there's no way to get good numbers on
that, but it's a story I hear from a lot of different places.
My company is working on some of these problems; our Firefox .MSI
builder is in private beta now, and we'll have more to say about that
soon, though not in this forum I think. This is just to say that we've
got some skin in this game, and our approach to helping big orgs manage
Firefox deployment in this new rapid-release world won't involve long
term support of outdated versions.
Enterprise software evaluation periods are long, Firefox development
cycles are not, and I don't think the question to answer there is how to
have the least negative impact in delaying Firefox development by
putting scarce resources towards long term support. I think a much
better question, and not coincidentally the one we're trying to answer,
is how can companies make the decision to upgrade quickly and with a lot
of confidence?
Our ideal is a box with one button and two lights. When new version of
Firefox shows up you plug it in and push the button; if it's green you
roll it out, if it's red you file bugs.
It may never be quite that easy but I think we'll be able to get pretty
close. We'll be relying heavily on the fact that Mozilla (who, again, I
am not a part of) has already got some really good if not widely
publicized tools available for just such circumstances: automated plugin
testing tools, a distressingly comprehensive test suite built right into
the tree, a few others that take a lot of the edge off of the evaluation
process if you're willing to bring them on board.
--
Mike Hoye
BespokeIO.com
Kai Engert
> On Tue, Jun 28, 2011 at 9:06 AM, Kai Engert<ka...@kuix.de> wrote:
>> On 28.06.2011 12:50, Axel Hecht wrote:
>>> nobody's forced to use them.
>> the new things.
I will tell another story, in the hope it is of value.
I've converted several people to use Linux and Firefox, and a part of
this is, I'm being called for help, if things don't work right.
Just weeks ago I helped a student who had trouble with the university's
Intranet application to manage courses, test registrations, etc. (which
uses Java).
It didn't work with Firefox 4. It worked with Firefox 3.6. Simple as that.
I'm really sorry, but my time did not allow me to investigate why. My
time was exhausted with searching for solutions and trying to find an
immediate workaround.
Luckily, Firefox 3.6 still gets security updates. I told the student:
"Use this separate FF 3.6.x icon only for your intranet application, and
the regular Firefox 4 for everything else".
(Of course, the student might mix that up sometimes, and even do regular
web surfing with the older FF. No problem, it still gets updates.)
Let's assume I had had this experience with different versions.
Let's say it worked in FF 4, but it didn't work in FF 5.
What now?
Given that FF 4 won't receive any security updates, can I reasonably
recommend someone to stay on that version?
No, I can't.
My personal conclusion of this story is, it is reasonable to have a
conservative branch in addition to the innovative branch, because you
have something to fall back to. Whenever programmers create new
software, they always break some things, regardless how hard you try.
Even if it's just a few edge cases, it will be true for at least the
couple of days until after the initial release of the innovative version.
Having overlapping innovative and conservative releases makes it
possible for web applications to gradually adopt to newer technology. I
think it's likely that the university will solve the incompatibility
issue within a couple of months, after more students start to use the
newer Firefox and report the problem.
With overlapping release cycles (or innovative vs. conservative), users
actually have a sane, recommendable way of going back, for the sake of
the compatibility. That student doesn't have a choice whether to use
that web app or not. It must be made to work, now, or she cannot
participate in that course tomorrow.
With the rapid-release-only cycle, what we have is: "Sorry, if the new
one doesn't work, you have to use the non-maintained version until
someone fixes the site issue."
If the user continues to use that older FF version, "because it appears
to work better", then those users remain unprotected.
Worse, by forcing ordinary users, who don't know how to downgrade on
their own, to upgrade to new features for getting security updates, you
force them into the risk of broken sites. You take away the option to
have just the early adopters do the testing, and upgrade the other
people later.
Let's say, I am the administrator of the student whom I've converted to
Firefox and Linux. Let's say, I have configured the computer to allow
security updates, but not major updates. Let's say, the student installs
the security update, and now the school web app is incompatible, and I'm
not around. What would have happened? The student would have booted
Windows and used IE. I don't think that's what we want to happen.
With an overlapping release cycle, I would make sure that every computer
user, whom I help to run their machines, will use the conservative
release, until I have had a chance to upgrade their machine and be
around to help them test their important sites.
I will stick to my opinion. A serious browser vendor must maintain
security releases, must provide releases with overlapping release
cycles, and must give people the choice to delay feature upgrades until
tech support is available.
Now, let's say, the authors of the web app aren't really experts. They
try to use the pieces they understand to make things work. "Hmm... it
doesn't work with Firefox 5? Hmm, ok let's look. Wait, Firefox 6 is
already out? Hmm... Should I fix it for Firefox 5 or Firefox 6?"
The lone programmers, who have been hired by a company to setup a
special internal application, they might not have the resources to deal
with regressions every 6 weeks. I would say, the small environments, who
setup an application, they are our users, too, and we should care for
them, by giving them security updates separate from features, if necessary.
Also, there are web apps that are simply fun, and it's not a big deal if
they break. However, I would guess there are web apps that people rely
on for their work. See the student schedule and coursework example. Or
imagine a "who's on standby" web app in a hospital. The admin of that
hospital might decide, it's no longer acceptable to have automatic
security updates enabled, if there's the risk of incompatibility.
On 28.06.2011 15:47, Mike Shaver wrote:
> Do you believe that enterprise adoption has been a meaningful part of
> Firefox's success so far? If so, to what extent, and for what
> reasons?
I believe a part of Firefox' success is that employees like Firefox so
much that they convinced their IT department to allow the use at work. I
would assume that Firefox is being used to access internal web
applications, too. If we start to become incompatible more often, then
either the users might stop using it, or IT departments might get bored
to adjust that frequently. I don't know, I'm just guessing. But my
personal opinion is, you have some regressions whenever you introduce
new features. And having releases more often means we have regressions
more often. The fact that those regressions might be edge cases doesn't
make that impact smaller, IMHO.
And Firefox is probably used on many corporate / governmental Linux
desktops.
I would say, a part of Firefox past success might have been, that our
security release policy was compatible with a lot of environments.
I appreciate the move to do innovative releases more often, but not if
it means a complete drop of support for older releases. I think people
need the choice of innovation vs. conservative.
Regards
Kai
Boris Zbarsky
> Our ideal is a box with one button and two lights. When new version of
> Firefox shows up you plug it in and push the button; if it's green you
> roll it out, if it's red you file bugs.
Except you do this with the beta, not the release, right?
If our release model stays as is, filing bugs after release is too late:
they won't get fixed for a few weeks, and in the meantime you're not
getting security updates.
-Boris
Mike Shaver
Some people take a few weeks to update anyway, even in our current
model. Mostly they survive.
Aurora or Beta would be best, though, so fixes or reversions happen in
time, or they have more time to get their apps updated if they depend
on some broken behaviour we fixed or similar.
Mike
Mike Hoye
> On 6/28/11 12:25 PM, Mike Hoye wrote:
>> Our ideal is a box with one button and two lights. When new version of
>> Firefox shows up you plug it in and push the button; if it's green you
>> roll it out, if it's red you file bugs.
> Except you do this with the beta, not the release, right?
help people build up test suites they can track against nightlies,
Aurora, and Beta, so that when the time comes to push that upgrade they
know their concerns have been met. That should complement both BigOrg's
IT processes and BigOrg's internal dev; bugs it finds are just as (and
in truth I think a lot more) likely to be bugs in internal webapps as
they are in the browser, and can be upstreamed either way before the
next releae.
--
Mike Hoye
BespokeIO.com