Getting on the release train - schedule & mechanics
Mark Banner
After considering several ways of structuring the repositories, I realised that the best and easiest way for Thunderbird to be on the release train is to match the Firefox schedules for merging and releases. Hence we'll do our merges on the say day as Firefox does theirs, our releases will potentially be on the same day, or maybe a few days after - we haven't finalised that bit of the plan yet.
Repository Structure
For the repository structure, we're going to match the mozilla-* repos:
- comm-central, mozilla-central, l10n-central
- comm-aurora*, mozilla-aurora, l10n-aurora
- comm-beta, mozilla-beta, l10n-beta
The mozilla-* and l10n-* repositories are the ones already created for Firefox.
Rules/Process
I think we should follow the same rules and process as the mozilla-* repos: http://mozilla.github.com/process-releases/draft/development_specifics/#channel-activities
In short:
- comm-central: general development channel
- comm-aurora: Pref off/backout fixes/features which have been exposed as problematic. Spot fixes. String Frozen.
- comm-beta: Very few changes, mainly small fixes which would prevent a final release. Builds should be pretty much release worthy at this stage.
The next merge for mozilla-central -> mozilla-aurora takes place on 24th May. That's when we'll be merging comm-central -> comm-aurora.
Hence Miramar.next will be string complete on 24th May, and feature complete (unless features are backed out/disabled).
We realise this is only 2 weeks after the Miramar freeze, but we need to join the release train, and we're also happy for Miramar.next to be a backend/security update if we don't have time for many UI improvements, though I suspect we'll be able to get a few improvements in during that time.
The next train would start 6 weeks after, i.e. 5th July.
Mark.
Robert Kaiser
> As Miramar won't be off the release train.
Sad to hear that, I thought you could be able to make that happen
already with that one.
> After considering several ways of structuring the repositories, I
> realised that the best and easiest way for Thunderbird to be on the
> release train is to match the Firefox schedules for merging and
> releases.
I think that's the best for everyone involved, yes.
> * We can't call our builds based on "Aurora" the same, as that would
> clash with the Aurora builds of Firefox. We're currently thinking up a
> new name, although I'm debating on keeping the repository name as aurora
> as that keeps the developer end of how the repositories align consistent.
I agree, let's have the repo be comm-aurora and everyone can still come
up with build names as needed.
> * comm-central: general development channel
> * comm-aurora: Pref off/backout fixes/features which have been exposed
> as problematic. Spot fixes. String Frozen.
> * comm-beta: Very few changes, mainly small fixes which would prevent
> a final release. Builds should be pretty much release worthy at this
> stage.
There will be a comm-release as well, right, which only has finals and
chemspills, just like for Firefox?
> The next merge for mozilla-central -> mozilla-aurora takes place on
> *24th May*. That's when we'll be merging comm-central -> comm-aurora.
Hmm, I hoped we could pre-seed the repos with what you ship/develop in
Miramar. I'm somewhat concerned with my SeaMonkey hat on (but Callek has
more overview there) that we might not have a security update with what
Firefox 5 is shipping if we can't jump onto that train right away, even
if that might mean almost no suite/mailnews changes compared to what
SeaMonkey 2.1 ships from the comm-2.0 repo. But I'll leave that to
discussions between you and Callek.
Robert Kaiser
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Mark Banner
> Mark Banner schrieb:
>> * comm-central: general development channel
>> * comm-aurora: Pref off/backout fixes/features which have been exposed
>> as problematic. Spot fixes. String Frozen.
>> * comm-beta: Very few changes, mainly small fixes which would prevent
>> a final release. Builds should be pretty much release worthy at this
>> stage.
>
> There will be a comm-release as well, right, which only has finals and
> chemspills, just like for Firefox?
as some of their stuff indicates there will be one, and some of it
doesn't. Additional, they've set up -aurora and -beta, but not -release
yet. So I'm waiting to see, but it doesn't affect us at this stage anyway.
>> The next merge for mozilla-central -> mozilla-aurora takes place on
>> *24th May*. That's when we'll be merging comm-central -> comm-aurora.
>
> Hmm, I hoped we could pre-seed the repos with what you ship/develop in
> Miramar. I'm somewhat concerned with my SeaMonkey hat on (but Callek
> has more overview there) that we might not have a security update with
> what Firefox 5 is shipping if we can't jump onto that train right
> away, even if that might mean almost no suite/mailnews changes
> compared to what SeaMonkey 2.1 ships from the comm-2.0 repo. But I'll
> leave that to discussions between you and Callek.
See my previous email about Miramar. If you haven't string frozen yet,
then you have to freeze and have locales complete their work by the 17th
- that is, if you want to use the -aurora, -beta repos for an FF 5
equivalent release.
Mark.
Ludwig Hügelschäfer
Hash: SHA512
Hi,
Mark Banner wrote on 03.05.11 12:36:
> In short:
>
> * comm-central: general development channel * comm-aurora: Pref
> off/backout fixes/features which have been exposed as problematic.
> Spot fixes. String Frozen.
is http://hg.mozilla.org/releases/comm-miramar/ the official repository
for creating Miramar?
TIA
Ludwig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBCgAGBQJNxD1XAAoJEA52XAUJWdLjVAMIAJkA2Cc8zdyJIg/GfTq5C62V
DsiEtJivUmXvEgrs6BS8ByL8FW63P9eJmv0wfmg8VEKoIPxswzh84UCVnluSXBFs
7QGHSLA7D/rYGTn2kGXCF+hGYrWnxHoyyrcNuvdX0Kb41CL2dIHh6GAFsrS7zB48
lN+TwwhhSUvUj8oF3kiT9Wcka33S+EeY9CC2QkS9YYBWxIQ41KM+RTM77mWARIjm
51w0dhqLbnA0Pr/Tg1/0YIOXgyzAvyUCj1XrThFjxVKt9bwwBp4BMXY8Vz4lABJr
JiCaNZTpTCxms7Usw9LgpUFcI947TMc3QZ8RtzRL0oPBeX3djVLyRQzlZYHbZac=
=emx5
-----END PGP SIGNATURE-----