60-week LTS, please! (enough for the current customers)

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

60-week LTS, please! (enough for the current customers)

Kohei Yoshino
I want to emphasize that MoCo folks should care about global markets,
not only North America. Thunderbird and Firefox are already getting
popular in Europe, Japan and other countries. Though I can't mention any
specific names except as listed here [1], even well-known companies are
adopting the Mozilla products.

We're not going enterprise. We can't act like Microsoft. But our humble
solutions like AutoConfig, LDAP support and custom update server [2] are
already working for them. We should be proud of that.

If we disregard the existence of those valuable customers, no doubt
we'll hurt our reputation as well as market share. That's also big
damage for the entire open source community. Our mission of encouraging
choice, innovation and opportunity online, must never be limited to
individual consumers. We must stop and think.

Mozilla's prior support practice (security and stability fixes) for one
major version was between 1 year and 1.5 years. So simply the 60-week
(1.15 years) LTS versions could be an acceptable range for the current
customers, while it doesn't require huge, unacceptable investments for
Mozilla.

That's my compromise proposal between our innovation and spoiled milk.
Other possible enterprise features like GPO support and MSI packaging
[3] are another steps. The most important issue we're facing is how we
continue relationships with the current customers.

[1] http://mozilla.jp/business/profiles/
[2] https://developer.mozilla.org/Special:Tags?tag=Enterprise
[3] https://wiki.mozilla.org/Enterprise:Wishlist

Again, please provide 60-week LTS.

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

Re: 60-week LTS, please! (enough for the current customers)

beltzner
Hi Kohei,

An impassioned plea with excellent data. Thank you. Two questions:

1. You ask for a 60 week LTS, but didn't specify what level of service would
be required. Can you elaborate? Is it simply ensuring that specific add-ons
or customizations continue to work? Security fixes? Holding the line on web
compatibility to preserve Intranet app functionality? (even if it means not
shipping a secuirty fix?) I do not think there is a shared understanding of
what "support" means. For example, we shipped security releases in the past
that almost certainly would have broken some websites, and potentially could
have broken the custom update server support.

2. What new web technologies or front end features would you be willing to
give up, or let other browsers take leadership on, in exchange for this
level of support? You don't need to be specific, just let us know if it's
Web Apps, Identity, Graphics Acceleration, Multimedia, HTML/CSS, JS,
Developer Tools, etc.

cheers,
mike
On 27/06/2011 6:58 AM, "Kohei Yoshino" <[hidden email]> wrote:
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: 60-week LTS, please! (enough for the current customers)

reuben.morais (Bugzilla)
On Mon, Jun 27, 2011 at 9:13 AM, beltzner <[hidden email]> wrote:

>
> 2. What new web technologies or front end features would you be willing to
> give up, or let other browsers take leadership on, in exchange for this
> level of support? You don't need to be specific, just let us know if it's
> Web Apps, Identity, Graphics Acceleration, Multimedia, HTML/CSS, JS,
> Developer Tools, etc.
>
>
Or a much better solution IMO, the people who are not happy with the current
model could help us achieve the middle ground between evolving the web and
supporting enterprise deployments.
If only a few of the several people who have been showing us the new release
cycle doesn't meet their needs were actually helping to build a better
support, I'm sure Mozilla would more interested in this.

Of course, that's the optimal solution - a different one suggested by Alon
Zakai in his blog
post<http://mozakai.blogspot.com/2011/06/long-term-support-for-firefox.html>,
is that companies start supporting Firefox commercially, backporting
security fixes and doing QA. According to all the emails dev.planning has
received lately, it's clearly something a lot of companies are interested
in.


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

Re: 60-week LTS, please! (enough for the current customers)

beltzner
Reuben,

I think that overlooks some less obvious time and material costs (product
management, code review, build and release support, communication and
support splitting across branches) but even if that were true, I would still
love an answer to the question.

The implication of longer support branches is a lack of concern on behalf of
those users that newer features will come slowly. It would be good to get a
sense of which feature work is of more importance than others, as part of
understanding that audience.

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

Re: 60-week LTS, please! (enough for the current customers)

Gijs Kruitbosch ("Hannibal")
In reply to this post by reuben.morais (Bugzilla)
On 27/06/2011 14:46 PM, beltzner wrote:

> Reuben,
>
> I think that overlooks some less obvious time and material costs (product
> management, code review, build and release support, communication and
> support splitting across branches) but even if that were true, I would still
> love an answer to the question.
>
> The implication of longer support branches is a lack of concern on behalf of
> those users that newer features will come slowly. It would be good to get a
> sense of which feature work is of more importance than others, as part of
> understanding that audience.
>
> cheers,
> mike


Would it be any less painful for Mozilla if companies were to support the MSI,
Group Policy support and other enterprise features that ease their pain, rather
than an additional branch? I would expect so, given that adding (and
maintaining!!) such features (AFAICT somewhat disjoint from the product itself)
generally will require less work from current module owners/peers, and creates
less technical debt than a complete branch that ends up 60/6 = 10 versions out
of date, at the extreme end of the spectrum. Would that be a more viable option?

To get back to your previous post, in particular this bit:

 > 2. What new web technologies or front end features would you be willing to
 > give up, or let other browsers take leadership on, in exchange for this
 > level of support? You don't need to be specific, just let us know if it's
 > Web Apps, Identity, Graphics Acceleration, Multimedia, HTML/CSS, JS,
 > Developer Tools, etc.

I agree that it's important to stress that a trade-off is required here, but on
the other hand I think it is unfair to suggest that there will be no more
JS/CSS/Web App/... work if enterprise work is taken on, especially so because
most people hacking on these bits of the core product would be unlikely to *all*
be good fits for implementing enterprise features and/or maintaining a branch.

Rather, I think if everybody maintaining core modules was to help maintain a
branch, that'd take up an arbitrary amount of time for each of them each
day/week/month (to backport/review patches, etc.) - say 5%. And that means that
ultimately less feature work can be done in each of those areas. Whether that
trade-off is viable (for 10/5/1/N% of work 'lost') is the next question (and I'm
not sure who should be making a final decision regarding this, but I'm thankful
it isn't me :-) )

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

Re: 60-week LTS, please! (enough for the current customers)

Boris Zbarsky
On 6/27/11 9:00 AM, Gijs Kruitbosch wrote:

> On 27/06/2011 14:46 PM, beltzner wrote:
> To get back to your previous post, in particular this bit:
>
>  > 2. What new web technologies or front end features would you be
> willing to
>  > give up, or let other browsers take leadership on, in exchange for this
>  > level of support? You don't need to be specific, just let us know if
> it's
>  > Web Apps, Identity, Graphics Acceleration, Multimedia, HTML/CSS, JS,
>  > Developer Tools, etc.
>
> I agree that it's important to stress that a trade-off is required here,
> but on the other hand I think it is unfair to suggest that there will be
> no more JS/CSS/Web App/... work

There could well be _less_ of it.   Hence the "other browsers take
leadership on" bit.

> especially so because most people hacking on these bits of the core
> product would be unlikely to *all* be good fits for implementing
> enterprise features and/or maintaining a branch.

The people core reviews are gated on right now are precisely the people
the branch reviews would be gated on.

> Rather, I think if everybody maintaining core modules was to help
> maintain a branch, that'd take up an arbitrary amount of time for each
> of them each day/week/month (to backport/review patches, etc.) - say 5%.
> And that means that ultimately less feature work can be done in each of
> those areas.

Right.

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

Re: 60-week LTS, please! (enough for the current customers)

Kyle Huey-2
In reply to this post by Kohei Yoshino
On Mon, Jun 27, 2011 at 3:57 AM, Kohei Yoshino <[hidden email]>wrote:

> Mozilla's prior support practice (security and stability fixes) for one
> major version was between 1 year and 1.5 years. So simply the 60-week
> (1.15 years) LTS versions could be an acceptable range for the current
> customers, while it doesn't require huge, unacceptable investments for
> Mozilla.
>



> Again, please provide 60-week LTS.
>

My (admittedly limited) understanding is that there are two issues here.

1) "Enterprises" don't want to deploy software that's only going to be
supported for 6 weeks.
2) "Enterprises" want time between upgrades to test things and ensure that
their mission-critical stuff still works before they upgrade.

This proposal only addresses (1).  Without some substantial overlap between
LTS versions (2) is not addressed and "enterprises" would have to jump
between LTS versions very quickly every 60 weeks.   I'm not an "enterprise"
IT manager, but I would expect that this situation is even worse because
instead of having ~ 6 weeks (the beta cycle for a branch) to test 6 weeks of
changes now there's ~ 6 weeks to test 60 weeks of changes.

I would expect that a setup like 2 LTS branches with a year of support being
refreshed every 6 months would be far more useful than a single shot 60 week
LTS branch ... but this also requires more resources.  Do you have contacts
with "enterprise" deployments in Japan and can you ask them what they need?

- Kyle

(I use "enterprise" in quotes since we're really talking about all large
deployments of Firefox in situations where moving the web forward as fast as
possible isn't one of the organization's core goals.  E.g. large
corporations, libraries, schools, etc.)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: 60-week LTS, please! (enough for the current customers)

Mike Hommey
In reply to this post by Kohei Yoshino
On Mon, Jun 27, 2011 at 07:57:53PM +0900, Kohei Yoshino wrote:
> Again, please provide 60-week LTS.

I'll add that "enterprises" are not the only ones that need long term
support. Everyone focuses on these, but only a few mentioned it before
so I'll repeat it here in the hope that it is noticed: the Mozilla
ecosystem needs long term support. And here, what I'm referring to is,
mostly, but not limited to, the content of this page:
http://www.mozilla.org/projects/mozilla-based.html
The list is far from complete, but will undoubtedly significantly shrink
if no effort, wherever it comes from, is done to have some kind of long
term support on a given branch.

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

Re: 60-week LTS, please! (enough for the current customers)

Kohei Yoshino
In reply to this post by beltzner
On 11/06/27 21:13, beltzner wrote:
> An impassioned plea with excellent data. Thank you.

Thank you for your reply :)

> 1. You ask for a 60 week LTS, but didn't specify what level of service would
> be required. Can you elaborate? Is it simply ensuring that specific add-ons
> or customizations continue to work? Security fixes? Holding the line on web
> compatibility to preserve Intranet app functionality? (even if it means not
> shipping a secuirty fix?) I do not think there is a shared understanding of
> what "support" means. For example, we shipped security releases in the past
> that almost certainly would have broken some websites, and potentially could
> have broken the custom update server support.

I meant minimum security/stability fixes, without any breaking changes,
to enable smooth updates and reduce QA/RelEng costs. I expect those
builds will have smaller set of changes than the current 3.6.x minor
updates.

> 2. What new web technologies or front end features would you be willing to
> give up, or let other browsers take leadership on, in exchange for this
> level of support? You don't need to be specific, just let us know if it's
> Web Apps, Identity, Graphics Acceleration, Multimedia, HTML/CSS, JS,
> Developer Tools, etc.

Sometimes engineering team would like to make notable changes to greatly
improve security, stability or user experience. For LTS, we should make
sure such changes are all described well, not just pointing the
corresponding bug list. For example:

* Firefox 3.6.4 aka Lorentz: implemented OOPP
* Firefox 3.6.9: supported X-FRAME-OPTIONS HTTP response header

I know those were documented in the relnotes and wiki.

And more importantly, such changes should be *disabled by default*.
So enterprise IT can examine those goodness and enable them later via
pref, in particular the AutoConfig mechanism.

Further discussion of this topic can be continued on Kai's thread.

On 11/06/27 22:32, Kyle Huey wrote:
> I would expect that a setup like 2 LTS branches with a year of support
being
> refreshed every 6 months would be far more useful than a single shot
60 week
> LTS branch ... but this also requires more resources.

In my understanding, rapid release + 2 LTS branch would look like:

5
6 / 5.0.1
    :
9 / 5.0.4
10 / 5.0.5
11 / 5.0.6 / 10.0.1
    :
14 / 5.0.9 / 10.0.4
15 / (5.0.x EOL) / 10.0.5
16 / 15.0.1 / 10.0.6
    :

It's ideal but costly. Mozilla has maintained 3 branches, 3.5.x, 3.6.x
and 4.0.x in parallel, so it's not impossible, but people may not accept
this plan.

> Do you have contacts with "enterprise" deployments in Japan and can
> you ask them what they need?

An IT manager I've talked said they would suit their testing method to
our rapid release cycle. That's pretty good (!) but I know, such people
are minority. Soon I'll try to talk with other managers to understand
how long they need for their testing process.

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

Re: 60-week LTS, please! (enough for the current customers)

L. David Baron
On Tuesday 2011-06-28 02:35 +0900, Kohei Yoshino wrote:

> In my understanding, rapid release + 2 LTS branch would look like:
>
> 5
> 6 / 5.0.1
>     :
> 9 / 5.0.4
> 10 / 5.0.5
> 11 / 5.0.6 / 10.0.1
>     :
> 14 / 5.0.9 / 10.0.4
> 15 / (5.0.x EOL) / 10.0.5
> 16 / 15.0.1 / 10.0.6
>     :
>
> It's ideal but costly. Mozilla has maintained 3 branches, 3.5.x, 3.6.x
> and 4.0.x in parallel, so it's not impossible, but people may not accept
> this plan.
>
> > Do you have contacts with "enterprise" deployments in Japan and can
> > you ask them what they need?
>
> An IT manager I've talked said they would suit their testing method to
> our rapid release cycle. That's pretty good (!) but I know, such people
> are minority. Soon I'll try to talk with other managers to understand
> how long they need for their testing process.

It seems like the key question here is how many "enterprise" (i.e.,
mass-installed by the computer owner) users we'd have with just
rapid release vs. how many we'd have with rapid release + LTS.  Do
we have any idea of these numbers?  (Do we have an estimate (not
just a guess) of how many such users we have now?)

-David

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

Re: 60-week LTS, please! (enough for the current customers)

Mike Connor-4
In reply to this post by Kohei Yoshino
On 27/06/2011 1:35 PM, Kohei Yoshino wrote:
> I meant minimum security/stability fixes, without any breaking changes,
> to enable smooth updates and reduce QA/RelEng costs. I expect those
> builds will have smaller set of changes than the current 3.6.x minor
> updates.

For the most part, that's what we've been shipping in 3.6.x already, so
the overhead isn't likely to change much.

>> 2. What new web technologies or front end features would you be willing to
>> give up, or let other browsers take leadership on, in exchange for this
>> level of support? You don't need to be specific, just let us know if it's
>> Web Apps, Identity, Graphics Acceleration, Multimedia, HTML/CSS, JS,
>> Developer Tools, etc.
> Sometimes engineering team would like to make notable changes to greatly
> improve security, stability or user experience. For LTS, we should make
> sure such changes are all described well, not just pointing the
> corresponding bug list. For example:
>
> * Firefox 3.6.4 aka Lorentz: implemented OOPP
> * Firefox 3.6.9: supported X-FRAME-OPTIONS HTTP response header
>
> I know those were documented in the relnotes and wiki.
>
> And more importantly, such changes should be *disabled by default*.
> So enterprise IT can examine those goodness and enable them later via
> pref, in particular the AutoConfig mechanism.
>
> Further discussion of this topic can be continued on Kai's thread.

I think you may have misunderstood the question.  The core assertion in
play is that any LTS-like model will impact the development and delivery
of new web technology in Firefox.  This is something we have directly
observed over the last five years, so I think we can treat that
assertion as true.  This then leads to the question of "what new
technology are we willing to trade off to support LTS versions?"  i.e.
what features will we not develop, or ship significantly later, in order
to accomodate an LTS version or versions.

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

Re: 60-week LTS, please! (enough for the current customers)

Cédric Corazza
In reply to this post by Kohei Yoshino
Le 27/06/2011 19:48, L. David Baron a écrit :

> It seems like the key question here is how many "enterprise" (i.e.,
> mass-installed by the computer owner) users we'd have with just
> rapid release vs. how many we'd have with rapid release + LTS.  Do
> we have any idea of these numbers?  (Do we have an estimate (not
> just a guess) of how many such users we have now?)
>
> -David
>

Hi,

I can speak only for my organization. As an IT manager, I had to
recommend recently to use IE 8/9 instead of Firefox… It is really
demoralizing for a Mozilla contributor.
The fact is that my organization depends on software editors that only
validate a specific version of Firefox.
I have to deal with 6200 PCs. Currently, I have 3 Web applications that
run better with Firefox than IE, but then, I have to deal with 3
different versions of Firefox to benefit of the editors' support…
That means I have to juggle with -no-remote -P and so, different
repositories, etc. Hence my recommendation.
A LTS support, which will only benefits from security and stability
patches will make happy both the software editors and the entreprises.
That would be 12 or preferably 18 months, with due dates clearly advertised.
This way, boths editors and enterprises can begin to test their apps 3
months before the deadline with what should be the "n - 1" Firefox
version of the rapid release cycle.
This way, entreprises in their call for tenders, can force the editors
to support the current Firefox LTS version and the next to come, as
timelines are known.
This is pretty much the way we deal with when we change our entreprise
PC --and OSes-- (though with much longer cycles).
BTW, the changes in UI isn't very important in that matter because the
user only interacts with the content window.
So, in my humble case, Mozilla would loose 6200 users.
I really hope that all the conversation about the rapid release cycle
will lead to a compromise.

Regards

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

Re: 60-week LTS, please! (enough for the current customers)

beltzner
How would your recommendations have been different with a slower release
cycle? It sounds like it has more to do with a lack of capabilities than
with the release cadence, but perhaps I misunderstood.

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

Re: 60-week LTS, please! (enough for the current customers)

Cédric Corazza
In reply to this post by Cédric Corazza
Le 27/06/2011 20:46, beltzner a écrit :
> How would your recommendations have been different with a slower release
> cycle? It sounds like it has more to do with a lack of capabilities than
> with the release cadence, but perhaps I misunderstood.
>
> cheers,
> mike

Yes, it is a lack of resources to spend on tests (for both editors and
entreprises).
Slower cycle releases allow them to focus on their own development to
add new features, to fix bugs, instead of, like in the current move, to
spend time to validate web apps each 3 months. For instance, we have
dozens of home coded web apps and we can't afford to spend that time
every 3 months. So this is very related to the release cadence. My
employer won't hire more people to palliate this. I guess this is the
same in other organisations: employers want their employees to do more,
with less people and less money.
So, Firefox rapid release cycle makes it more expensive in that matter
than the snail IE.

Regards

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

Re: 60-week LTS, please! (enough for the current customers)

Boris Zbarsky
In reply to this post by Cédric Corazza
On 6/27/11 2:35 PM, Cédric Corazza wrote:
> This way, boths editors and enterprises can begin to test their apps 3
> months before the deadline

For what it's worth, this in many cases didn't happen with Firefox 4
(where people started testing the day _after_ release)...  I have pretty
low confidence in it happening in the future.

A more likely scenario if this approach is taken is that people will
test after release, completely ignoring betas, and then report bugs and
expect an update that they will the update to from the previous LTS
release.  Which is why LTS releases would need to overlap.

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

Re: 60-week LTS, please! (enough for the current customers)

Steve Wendt
On 6/27/2011 12:59 PM, Boris Zbarsky wrote:

> people will test after release, completely ignoring betas, and then
> report bugs and expect an update that they will the update to

*This* is reality.

I've frequently gotten responses along the lines of "we don't support
betas / pre-releases" when reporting issues with a new Gecko version.  I
wish there was a way to improve that, but I'm not sure that there is;
testing early is not part of this mentality, especially when they feel
they have their own development issues to worry about.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: 60-week LTS, please! (enough for the current customers)

Ben Bucksch
In reply to this post by Kohei Yoshino
On 27.06.2011 19:48, L. David Baron wrote:
> It seems like the key question here is how many "enterprise" (i.e.,
> mass-installed by the computer owner) users we'd have with just
> rapid release vs. how many we'd have with rapid release + LTS.  Do
> we have any idea of these numbers?  (Do we have an estimate (not
> just a guess) of how many such users we have now?)

That is impossible to "estimate (not just guess)". These users don't
even know themselves yet what they will do.

They do know that they cannot roll out a new release with new features
and unknown changes every 6 weeks across the whole enterprise.

So, effectively, the reality probably is that they stay on old releases,
don't get security updates, and are insecure, and hope for the best (or
think they are safe because they have a firewall).

Worst case, the web access will be locked down in those companies, to
counter the risk. Which hardly helps the open web. But that's all
speculation, because *nobody* knows a solution. They are being put into
an impossible solution with no realistic way out.

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

Re: 60-week LTS, please! (enough for the current customers)

Mike Shaver
On Mon, Jun 27, 2011 at 5:04 PM, Ben Bucksch
<[hidden email]> wrote:
> They are being put into an
> impossible solution with no realistic way out.

We've heard already in these threads that some admins are going to be
revalidating to keep up, since they understand that they're going to
see fewer changes per release, and that they actually have a longer
quiet period before release than they had with previous releases.  So
the problem clearly isn't impossible, and I don't think the hyperbole
helps advance the discourse here.

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

Re: 60-week LTS, please! (enough for the current customers)

Ben Bucksch
Mike Shaver wrote:
> Ben Bucksch wrote:
>> They are being put into an
>> impossible solution with no realistic way out.
>
> some admins are going to be revalidating to keep up [...] So,
> the problem clearly isn't impossible, and I don't think the hyperbole
> helps advance the discourse here.

This wasn't hyperbole, but my honest belief. I didn't mean "impossible
situation" in the sense of "cannot be done in theory", but "cannot be
done given the politics, policies and procedures and realities in that
company".

I've worked for the Foreign Ministry of Germany, 5000 seats, and they
were severely behind (!) the stable Debian. And you know how outdated
Debian stable is when it's released.

I also know from CSC that we, although being software developers, were
not allowed to have the latest software, because it was not approved by
headquarters yet. It had been released a few months ago.

I read about IBM's problems on Mike Kaply's blog, that the responsible
person feels he is being put in an impossible situation.

All information I have points to big companies not following this. I
don't question that there will be some that will cope, but I honestly
think the majority will feel like that and will not follow.

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

Re: 60-week LTS, please! (enough for the current customers)

Robert O'Callahan-3
In reply to this post by Mike Connor-4
On Tue, Jun 28, 2011 at 5:55 AM, Mike Connor <[hidden email]> wrote:

> I think you may have misunderstood the question.  The core assertion in
> play is that any LTS-like model will impact the development and delivery of
> new web technology in Firefox.  This is something we have directly observed
> over the last five years, so I think we can treat that assertion as true.
>

It's somewhat vacuously true; anything we do will have impact on anything
else we do *somehow*.

The real question is, how much contributor time has been consumed
evaluating, backporting, QAing and shipping security fixes for stable
branches? And would that time be worth the benefit in the future?

From my perspective in graphics, layout and video, although we've spent a
lot of time over the years doing security fixes in ways that have definitely
slowed down development of new features, we've spent very little of that
dealing specifically with stable branches. At a wild (wild) guess I would
say less than an hour a week per developer, on average.

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]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12