<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 15/09/2012 06:14, Kent James wrote:<br>
    </div>
    <blockquote cite="mid:50540EAB.2000605@caspia.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <br>
      <div class="moz-cite-prefix">On 9/14/2012 9:30 PM,
        Unicorn.Consulting wrote:<br>
      </div>
      <blockquote cite="mid:50540461.5030406@gmail.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        <link href="chrome://translator/skin/floatingPanel.css"
          type="text/css" rel="stylesheet">
        <div class="moz-cite-prefix">On 15/09/2012 1:42 PM, Kent James
          wrote:<br>
        </div>
        <blockquote cite="mid:50540047.4040003@caspia.com" type="cite">I
          have an alternate proposal for the release planning. <br>
          <br>
          So my proposal is that we do "intermediate releases" to the
          main release channel starting at either TB 22 or TB 23. These
          would be releases from the main central/aurora/beta/release
          repositories so would not need additional repos with all of
          the complications of that. <br>
        </blockquote>
      </blockquote>
    </blockquote>
    Assuming these are based on the equivalent Gecko versions, then we
    would also need to consider back-porting of the core security fixes
    to those releases for each of the .0.1 releases.<br>
    <br>
    <blockquote cite="mid:50540EAB.2000605@caspia.com" type="cite">
      <blockquote cite="mid:50540461.5030406@gmail.com" type="cite"> 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.<br>
      </blockquote>
    </blockquote>
    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 <a
      href="http://www.mozilla.org/thunderbird/organizations/faq/">ESR
      FAQ</a> has a diagram showing this overlap. Hence, this allows for
    the .0.1 and .0.2 releases.<br>
    <br>
    <blockquote cite="mid:50540EAB.2000605@caspia.com" type="cite"> So
      to interpret what I think you are saying in terms of repos and
      channels, we proceed with 17.0 as planned - but it is not the ESR
      release. We freeze mozilla-central in comm-aurora, release, and
      beta so that eventually release, beta, and aurora are all on
      gecko17. New work is landed in comm-central (with current gecko),
      and selected patches are landed in aurora (with a+) as needed in
      17.1 (which will also be ESR). After 17.1 releases, we restart the
      central->aurora->beta migrations as now (but no new releases
      until 24.0 then 24.1 ESR)<br>
    </blockquote>
    I think my other message to this thread covers this slightly
    differently. What I think I could do with though, is a clear
    statement of the problem you're trying to solve here, as this
    doesn't just sound like just allowing an intermediate release of
    features. Earlier in the thread you mentioned there's issues fixing
    bugs due to L10n. Are these flagged as tracking-thunderbird17? Can
    you also provide some examples?<br>
    <br>
    Thanks<br>
    Mark.<br>
  </body>
</html>