<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Over the last couple of weeks, I've been talking to various people
    about our strategies for the new schedule driven releases.<br>
    <br>
    Originally, we weren't sure if to go for a three or four channel
    process (<a
href="http://mozilla.github.com/process-releases/draft/development_overview/">see
      Powers of Ten section on the FF overview for info</a>), we were
    thinking of something like:<br>
    <ul>
      <li>Develop our trunk/nightly channel using Experimental as the
        back-end</li>
      <li>Thunderbird Beta using Beta for the back end</li>
      <li>Thunderbird Release using Release<br>
      </li>
    </ul>
    We would have then used the mozilla-central/nightly back-end as the
    Canary system.<br>
    <br>
    However, I think the biggest concern with this is for L10n - the way
    Firefox is being set up, is that the Experimental channel (now
    called Aurora) is string frozen for L10n. Hence, if we develop our
    equivalent of experimental, and then expect L10n to localise on
    Beta, I can see some localisers getting confused as to which channel
    they are localising where.<br>
    <br>
    I think there's also the fact that if we haven't got some
    development on mozilla-central then we may miss some core bugs that
    we don't see until a merge to Aurora.<br>
    <br>
    Therefore, I think we should go for a one-to-one mapping of:<br>
    <ul>
      <li>Thunderbird trunk/nightly uses Firefox nightly</li>
      <li>Thunderbird Experimental (name TBD) uses Firefox
        Experimental/Aurora</li>
      <li>Thunderbird Beta uses Firefox Beta</li>
      <li>Thunderbird Release uses Firefox Release</li>
    </ul>
    With this mapping, we'll also definitely need the Canary system
    completing for the trunk builds.<br>
    <br>
    I'm currently not specifying repository names as I'm just about to
    start discussions with the l10n folks about how to structure the
    repos, which I think will help shape what we need to go with.<br>
    <br>
    Feedback and thoughts welcome.<br>
    <br>
    Mark.<br>
  </body>
</html>