Can we at least adjust the ESR release length so that they fall on even numbered Geckos? Then they'll never end up on a version that is not shared with a b2g branch.
- Kyle On Thu, Jul 31, 2014 at 10:18 PM, Lukas Blakk <lsbl...@mozilla.com> wrote: > Hello, > > When the ESR branch was initially created it was done so in a manner of > intentional impermanence, the thinking being that consumers of this channel > would eventually establish a way to switch over onto our 6 week rapid release > mainline builds. With last week’s ESR31 we are pushing the limits of the > original timeframe and it’s time to make a call on how to proceed with this > population of users with an intent of creating permanence. > > In its present state, a strong community has built up around this channel and > pacing of major version bumps. The enterprise mailing list is active but not > high-volume. There are two community contributors who took on the work of > administrating the mailing list and they provide support as well on how to > customize deployments. Since this branch/channel was created with the > intention of killing it off down the road, we do not do any external > marketing of the ESR. The user base can be generally distributed into three > buckets: large organizations with over 100K instances, 2-10K organizations, > and then ones under 1K. There are over 5500 members on the mailing list, and > in order to get details about use a query was sent to the list in order to > collect information on the value of continue providing this channel. About 80 > responses were received in 2 weeks. > > Given: > > * we have a strong, self-supporting community > * building and maintaining ESR has become a smooth process which uses very > few resources (one channel, minimal builds on checkins, single QA sign off > every 6 weeks) > * Chrome is now providing enterprise support > (http://www.google.com/intl/en/chrome/business/browser/) > * there are at least 2M users on this channel and we estimate there to be > more if we factor in Linux distributions > > The approach going forward is to: > > * continue providing ESR builds as a permanent channel dedicated to the > criteria we laid out in its creation > * plan a marketing push around the existence of ESR (update docs, revamp the > org web page, promote the channel externally) > * commit to iterating on the processes built around of this channel and > explore potential improvements to pacing, packaging, and other customizations > * make a project of getting FHR/Telemetry data from these deployments where > permitted so that we have information on long-term usage that could be > missing from mainline > > For that last point, many of the respondents to the questions I raised on the > list said they already could do, or would look into doing, Telemetry/FHR > reports if they had more visibility into what the data collected was and also > some expressed interest in having access to that collected data. Data from > long term support build users might unlock stability and security information > that we do not currently discover in our rapid releases. > > There is value to this channel both in loyalty of users, reaching people at > work where they likely spend more of their online time, and maintaining a > share of desktop browser usage. Let’s take this already strong community, > and look at how we can grow it for the benefit of the users and our products. > > Cheers, > Lukas > > _______________________________________________ > dev-planning mailing list > dev-plann...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-planning _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
