Fwd: TB Summary of release discussion

Ludovic Hirlimann ludovic at mozilla.com
Thu Sep 20 12:45:11 UTC 2012


On 9/20/12 1:10 AM, Unicorn.Consulting wrote:
> On 20/09/2012 12:29 AM, Kent James wrote:
>>
>> On 9/19/2012 1:31 AM, Mark Banner wrote:
>>> On 18/09/2012 17:03, Kent James wrote:
>>>>
>>>> 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).
>> That's a good point. I had not thought of the issues of the overlap.
>>>
>>>> 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.
>> OK that's news to me, thanks for pointing that out.
>>
>> With this discussion,  I think that I am going back to my earlier
>> position, that the best way to use an intermediate release would be
>> to release a Thunderbird 23 or 22, so that we would get some
>> additional user feedback on issues before we get locked in for
>> another year.
>>
>> What do you think, Matt?
> I have no real objection.
So you guys aren't worried that 6 or 12 weeks would be very short to
gather feedback bubble it up and have things fixed ? I'd rather have 20
or 21 as a target train.

-- 
@lhirlimann on twitter
https://wiki.mozilla.org/Thunderbird:Testing

my photos http://www.flickr.com/photos/lhirlimann/collections/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120920/7a11062c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4435 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120920/7a11062c/attachment.p7s>


More information about the tb-planning mailing list