Fwd: TB Summary of release discussion
mbanner at mozilla.com
Wed Sep 19 08:31:28 UTC 2012
On 18/09/2012 17:03, Kent James wrote:
> On 9/18/2012 1:11 AM, Mark Banner wrote:
>> On 15/09/2012 06:14, Kent James wrote:
>>> On 9/14/2012 9:30 PM, Unicorn.Consulting wrote:
>>>> On 15/09/2012 1:42 PM, Kent James wrote:
>>>>>> I think that an ESR release should not become an ESR release at
>>>>>> the same time the general release occurs. ESR is really aimed at
>>>>>> Business and they are in no hurry for new releases, so we do what
>>>>>> business has been doing for almost as long as they have had
>>>>>> computers, wait for the .1 release. That is there will be a 17.1
>>>>>> ESR and a 24.1 ESR or whatever no time frame as such, but
>>>>>> released reasonably soon after the main release with fixes as
>>>>>> required, including a roleup of the now almost mandatory 0.1 and
>>>>>> 0.2. Releases. The general user base can come along for the ride
>>>>>> to point one, but point one is the ESR release.
>>>> ESR has been designed with new features at the time of the ESR
>>>> being considered. There is an overlap of 2 releases on the ESR
>>>> channel to allow organisations time to switch over and for any
>>>> critical issues to be resolved. The ESR FAQ
>>>> <http://www.mozilla.org/thunderbird/organizations/faq/> has a
>>>> diagram showing this overlap. Hence, this allows for the .0.1 and
>>>> .0.2 releases.
> I think that the concern that Matt and I are showing is that each new
> *. release seems to come with a few new critical issues that are not
> resolved until the *.0.1 or *.0.2 release. Currently ESR 17 is the
> same as TB17 and has the same initial instability.
> Why is that needed? Why not delay the ESR release relative to the main
> release until some period of time has elapsed for those instabilities
> to get worked out? ESR has no rush to it.
I can understand the concern, but I don't believe it is really critical
to ESR. Despite our mentions about testing the changes, I'm pretty sure
some organizations won't start widely testing until the next ESR is
actually released. So if there are issues that affect them specifically,
they may not get reported until we release the ESR. If we delayed
releasing that ESR for a couple of point releases, then they would be in
the case where the old ESR version would be unsupported, but they might
not be able to upgrade to the new version due to the issues.
The overlap is there for exactly this reason - upgrade straight away if
you can, but if not, you've got 12 weeks to resolve any issues (or get
us to resolve them).
> The problem we are trying to solve is preventing the *.0.0
> instabilities from hitting the ESR channel, so that ESR users do not
> have to go through a period of pain before the release stabilizes.
> Matt's proposal does this better than my initial proposal.
Something else to point out here I think, is that when we release ESR
17.0, only syadmins that choose to upgrade their uses to the new ESR
version will do so. As there will be two more ESR 10.0 releases (one in
sync with ESR 17, the second in sync with 17.0.1), I don't see us
prompting 10.0 users to do a major upgrade until 17.0.2 is released and
10.0.x is obsolete.
> The current example of a bug where potentially better fixes were not
> considered due to L10n constraints is "[Bug 791311] Don't disable the
> menubar for existing users", thought that is just a current example.
> The more general point is that we should not let L10n constraints
> prevent us from presenting ESR users with the optimal fixes for bugs.
> That may or may not be an issue in the current ESR release, if not
> then ESR could happen at 17.0.1 or 17.0.2
Just as an example, for specifically for an ESR, we might want to have
an option whereby sysadmins can choose that Thunderbird does not
automatically remove the menubars (most sysamdins have set-ups that
allow them to set default prefs etc). We've done this type of thing
for them and it may be appropriate here.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning