<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 09/08/2012 06:18, Ludovic Hirlimann
      wrote:<br>
    </div>
    <blockquote cite="mid:5023483B.4020406@mozilla.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      so<br>
      <blockquote type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=ISO-8859-1">
        <div class="" id="magicdomid11">
          <ul class="list-bullet1">
            <li><span class="">All releases will be based on Gecko ESR
                releases</span></li>
          </ul>
        </div>
        <div class="" id="magicdomid12">
          <ul class="list-bullet2">
            <li><span class="">To provide a more stable core for
                releases, so that we're not affected so much by Gecko
                changes</span></li>
          </ul>
        </div>
        <div class="" id="magicdomid13">
          <ul class="list-bullet1">
            <li><span class="">The ESR model will remain the same,
                separate from the mainstream channel</span></li>
          </ul>
        </div>
      </blockquote>
      <br>
      Hum why that besides the channel change they'd be identical, I
      don't see the need to keep two channels with the same product.
      What's the point in keeping ESR and release based on the same ESR
      code ?<br>
    </blockquote>
    <br>
    Keeping them separate gives the opportunity for intermediate
    releases if we have a significant amount of features ready. If we
    didn't have separate channels, then we wouldn't be able to do those
    intermediate releases because we'd be breaking the ESR promise. As
    we don't yet know the amount of contributions that we'll get going
    forward I feel it would be better to keep the opportunity available
    rather than take it away. We can always review it in a year or two.<br>
    <br>
    <blockquote cite="mid:5023483B.4020406@mozilla.com" type="cite"> I
      don't see the point keeping Aurora and Beta. From the way it
      currently works we don't benefit much from having Aurora and Beta
      - most Major regression are found at release time not on Aurora
      nor beta and if they are they are found too close to the release
      dates to be actionable. Maintaining Aurora is too time consuming
      in terms of QA, release management and engineering for US to keep.
      I do see the l10 arguments but I think we can do it in another way
      (eg anyway most of the l10n strings from gecko we'll get for free
      from Ff).<br>
    </blockquote>
    Having Aurora will give us an additional slightly-stable channel,
    but also my main argument would be for L10n - it is where they work
    from now, and I don't think that it is something worth changing. It
    also gives them stability, clear checkin needs, and continuous
    integration rather than big spurts of Thunderbird strings when we
    decide it is necessary for a release, that something that is much
    easier to work with, and it has certainly seemed a lot easier to get
    localisations complete under the rapid release scheme, especially
    with the improved tools to have now that work with the rapid release
    model.<br>
    <br>
    From a release management and engineering perspective, I've never
    found EarlyBird/aurora really time consuming. The builds are there
    and they run when necessary, whilst it consumes some resources, it
    is no where as near significant as trunk.<br>
    <br>
    <blockquote cite="mid:5023483B.4020406@mozilla.com" type="cite">
      I'de like us to consider the following :<br>
      <br>
      <ul>
        <li>We base release on ESR</li>
        <li>When we have enough "new features"+bug fixes we cut a beta</li>
        <li>Beta get's tested and released over a 3/4 week period</li>
        <li>Next beta comes out a few months later which gives us time
          to chew on beta data (bugs, feedback etc ...)</li>
      </ul>
    </blockquote>
    The problem I see here, is that this gives us a semi-random time as
    to when releases occur, which makes planning for everyone a lot
    harder. Additionally, if you're looking at a month-cycle for a beta,
    then I think you'll soon start hitting the place where to get a few
    betas, you'll actually then be hitting the preparation cycle for the
    next ESR based release.<br>
    <br>
    <blockquote cite="mid:5023483B.4020406@mozilla.com" type="cite">
      <ul>
      </ul>
      What I'm proposing looks a lot like what happened for 3.0 or 3.1
      eg reverting back to pre rapid release. I think this works better
      with how I see Thunderbird evolving and will give us more stable
      releases.<br>
    </blockquote>
    The problem there is that there is a lot more co-ordination to do
    with 50+ l10n teams for getting the Thunderbird strings localised
    and in the right place at the right time. Keeping Earlybird/aurora
    gives us that with relatively low cost.<br>
    <br>
    Mark.<br>
    <br>
  </body>
</html>