Can we release new locales on stable branches out of band?
Axel Hecht
I've been thinking about how to unblock adding new beta locales on 3.6.x
from the release mechanics, and I'd like to propose to just ship them
independently of the actual 3.6.x build. That is, say, we'd ship 3.6.7
ast a week or two after we ship 3.6.7 for all the existing locales.
I'm not sure if I got all the axes covered, but here's what I have in mind:
Localizers and their community:
They'd be getting builds when they're done, allowing us to be more agile
in releasing new locales, and keeping their momentum.
Build:
With the current infrastructure, we should be able to trigger repacks
and such well after the repackaged en-US build is done. We might have to
tag manually, or tweak the existing factories a bit, but I would imagine
that's doable. Caveats would be the book-keeping files for
l10n-changesets and shipped-locales, and the release tags on those. That
somewhat depends on how much the information on those needs to be
reflected, and tagged, though.
QA:
New locales are few, and we'll be better in terms of load as we're out
of band with the en-US release, so I'd expect our story here to improve
rather than worsen?
Web:
Just an update to product-details, this should be the easiest piece.
External deps:
AV vendors and mirrors is what I come up with, I'd need comments from
other people on how much we actually need to do here.
Things I've forgotten or don't know about:
---fill in---
Does that sound like a useful idea?
Axel
Seth Bindernagel
Axel Hecht wrote:
> Hi,
>
> I've been thinking about how to unblock adding new beta locales on 3.6.x
> from the release mechanics, and I'd like to propose to just ship them
> independently of the actual 3.6.x build. That is, say, we'd ship 3.6.7
> ast a week or two after we ship 3.6.7 for all the existing locales.
Shipping independent to an actual build seems like a good idea. For
one, it will provide a quicker response time to local communities
wanting desperately to release earlier than we can provide right now.
Quick note for those not familiar with "ast". That's the language code
for Asturian (spoken in Spain) and is one example of a new localization
(with a waiting community) in our release queue right now.
>
> I'm not sure if I got all the axes covered, but here's what I have in mind:
>
> Localizers and their community:
> They'd be getting builds when they're done, allowing us to be more agile
> in releasing new locales, and keeping their momentum.
This is a critical spot where we have not delivered in the past. New
localization communities will appreciate this agility.
>
> Build:
> With the current infrastructure, we should be able to trigger repacks
> and such well after the repackaged en-US build is done. We might have to
> tag manually, or tweak the existing factories a bit, but I would imagine
> that's doable. Caveats would be the book-keeping files for
> l10n-changesets and shipped-locales, and the release tags on those. That
> somewhat depends on how much the information on those needs to be
> reflected, and tagged, though.
I don't know specifics about the releng technology or possibile
limitations here, but I would add that this will *not* occur with such
regularity that it might become a burden for those involved. We
probably will only add a handful of new locales throughout a release cycle.
>
> QA:
> New locales are few, and we'll be better in terms of load as we're out
> of band with the en-US release, so I'd expect our story here to improve
> rather than worsen?
>
> Web:
> Just an update to product-details, this should be the easiest piece.
>
> External deps:
> AV vendors and mirrors is what I come up with, I'd need comments from
> other people on how much we actually need to do here.
>
> Things I've forgotten or don't know about:
> ---fill in---
Marketing and PR might need to figure out where to mention that we have
added new locales, if they care to mention that when we do.
>
> Does that sound like a useful idea?
This sounds useful to me.
Ben Hearsum
Hash: SHA1
I think this is a great idea for the reasons that you and Seth have
pointed out. However, the build infrastructure would need a fair bit of
work to do this properly. There's multiple areas (signing being the
trickiest) that simply would not be able to do this right now.
I don't want to get into the game of doing these by hand. It's easy to
make mistakes that way, which should be avoided for release work
whenever possible.
I'm sure it could be done, it would just have to be prioritized and
worked on.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkxEomsACgkQJE25Np0n+NvKFwCeILDV++IGAN8d+tICxPytizsr
8y4AoKVnurEuF5kgdIVI+3b0aaL85FmN
=hMN4
-----END PGP SIGNATURE-----
Axel Hecht
How does signing actually work these days?
Are there other things that wouldn't work? I guess most of things are
triggerable schedulers vs steps?
Axel
John O'Duinn
I've put this proposal in context of the recent FF3.6.8 release to walk
through concrete details and make sure we share the same understanding.
The proposal is to change
...from this:
* Ship FF3.6.8 with the usual locales on 23-jul-2010. Once a new locale
(like "ast") is ready, add "ast" to the list of locales being shipped in
the FF3.6.9 release. Later, FF3.6.9 would ship with usual-locales-plus-ast.
...to this:
* Ship FF3.6.8 with the usual locales on 23-jul-2010. Once a new locale
(like "ast") is ready, then do a build/test/release cycle for
FF3.6.8-for-ast-locale-only. This would be done at some time *after*
FF3.6.8 shipped, and *before* the FF3.6.9 release. This would not modify
the other, already shipped, locales of FF3.6.8. Later, FF3.6.9 would
ship with usual-locales-plus-ast.
If that is a correct summary of your proposal, it would require changes
to our infrastructure; we currently do not support doing a release of
one locale out of cycle from the rest of the same release. As bhearsum
notes, doing this manually is not an option we're comfortable with given
the complexity and risks involved, so we'd need to change automation for
this. Of course, its all software, so almost anything is possible, but
it would take time to scope out, be non-free to implement, and also
impact RelEng/l10n/QA every time we release a locale out of Firefox
release cycle like this. Therefore, we should all be clear on the
benefits, and opportunity costs, of this proposal before we start down
this path.
1) In this proposal, I understand the localisers of the "ast" locale,
would see the very first release of "ast" sooner, without having to wait
for the next scheduled Firefox release. Is that the objective here, or
are there other gains in this proposal that I am missing?
2) Do the l10n nightlies we already produce on different branches help
the "ast" localisers in terms of community momentum?
Obviously, if I'm misunderstanding the proposal, please correct me, ok?
tc
John.
=====
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Axel Hecht
> hi Axel/SethB;
>
> I've put this proposal in context of the recent FF3.6.8 release to walk
> through concrete details and make sure we share the same understanding.
> The proposal is to change
>
> ...from this:
>
> * Ship FF3.6.8 with the usual locales on 23-jul-2010. Once a new locale
> (like "ast") is ready, add "ast" to the list of locales being shipped in
> the FF3.6.9 release. Later, FF3.6.9 would ship with usual-locales-plus-ast.
There seem to be variants of this in the heads involved. Also, there are
a few details on the technical execution etc that need to be sorted out.
Sethb started a mail thread to get a meeting on this with LegNeato and
beltzner.
Detail question, are the release factories going to bust on update
creation like the nightlies do for new locales?
> ...to this:
>
> * Ship FF3.6.8 with the usual locales on 23-jul-2010. Once a new locale
> (like "ast") is ready, then do a build/test/release cycle for
> FF3.6.8-for-ast-locale-only. This would be done at some time *after*
> FF3.6.8 shipped, and *before* the FF3.6.9 release. This would not modify
> the other, already shipped, locales of FF3.6.8. Later, FF3.6.9 would
> ship with usual-locales-plus-ast.
Yep, this is what I'd like to get to.
> If that is a correct summary of your proposal, it would require changes
> to our infrastructure; we currently do not support doing a release of
> one locale out of cycle from the rest of the same release. As bhearsum
> notes, doing this manually is not an option we're comfortable with given
> the complexity and risks involved, so we'd need to change automation for
> this. Of course, its all software, so almost anything is possible, but
> it would take time to scope out, be non-free to implement, and also
> impact RelEng/l10n/QA every time we release a locale out of Firefox
> release cycle like this. Therefore, we should all be clear on the
> benefits, and opportunity costs, of this proposal before we start down
> this path.
Looking just at the releng side of things, wouldn't it be "good to have"
anyway, if we could respin a particular locale? If for nothing but a
busted buildbot-configs clone :-/, or a funky slave or any other odd
sparse bug during the release run? I'd be happy if new locales could
pile on top of those arguments.
> 1) In this proposal, I understand the localisers of the "ast" locale,
> would see the very first release of "ast" sooner, without having to wait
> for the next scheduled Firefox release. Is that the objective here, or
> are there other gains in this proposal that I am missing?
> 2) Do the l10n nightlies we already produce on different branches help
> the "ast" localisers in terms of community momentum?
I'd like to get new locales to ship "soon". If we take dveditz's
proposal from release-drivers, new locales should land early in the
cycle, so some 4 weeks up front? Miss that a bit, and the release to be
in could easily be two months out. Taking the 6 weeks cadence we don't
have, that is. And we don't know the version number of that release yet,
either.
The gap between a new locale being ready to ship and when we actually
ship it is one of those that break localizer's momentum, and, tbh,
l10n-driver's momentum on those new locales, too.
Regarding the nightlies, I advertise them as much as I can, but getting
more than one or two people on them for new locales seems to not work at
this time. ast has one, gd two. More constructive exposure ala
https://bugzilla.mozilla.org/show_bug.cgi?id=543629 might help one day.
> Obviously, if I'm misunderstanding the proposal, please correct me, ok?
Nope, you got it allright.
Axel