/l10n repository frozen for Firefox 3 Beta 5
Axel Hecht
as announced previously, we're locking down the l10n rep for Beta 5 now.
After Beta 5 is cut, there will be another landing window. We'll follow
up on that later, when we know more. Something in the order of 2-3 weeks
until RC1 freeze date, though.
If you have stuff to land that does block Beta 5, please have a bug for
that specific issue and make it block
https://bugzilla.mozilla.org/show_bug.cgi?id=423635. Mic, I, or someone
else from the usual suspects will take a look and either approve or not
that check-in.
There are still some patches landing on the code side, though nothing of
l10n impact, of course.
On the l10n side, we'll be using the time to create the list of shipped
locales.
Thanks, and to those that care, happy easter.
Axel
Rimas Kudelis
is mail/ also locked?
RQ
Axel Hecht rašė:
Damjan Georgievski
> up on that later, when we know more. Something in the order of 2-3 weeks
> until RC1 freeze date, though.
Do you expect there'll be a landing window for l10n after RC1?
Or the 2-3 weeks after b5 will be the last?
--
damjan
Axel Hecht
> Hi Axel,
>
> is mail/ also locked?
I'd rather see you not check in to mail or suite. That's as rude as I get.
Is there a lot going on there?
Axel
Axel Hecht
An RC is a release candidate. There shouldn't be any scheduled work to
happen after RC1. It's a tad unrealistic to say that we're only going to
need one RC, but the point of an RC is that it's a release candidate,
not a milestone to get there.
Thus, don't plan for work to happen post RC1, web-work withstanding.
I'll let Pascal detail on that.
Axel
Rimas Kudelis
> Rimas Kudelis wrote:
>> Hi Axel,
>>
>> is mail/ also locked?
>
> I'd rather see you not check in to mail or suite. That's as rude as I get.
>
> Is there a lot going on there?
No, not much. Only one checkin so far.
Rimas
Simon Paquet
>Hi all,
>
>as announced previously, we're locking down the l10n rep for Beta 5 now.
Since when do you have the authority to lockdown the whole l10n
repository just for one single application? Did I miss the "Firefox
Superiority" post here or elsewhere?
As far as I'm concerned (and I'm speaking for the Calendar Project here)
calendar is still open and will stay open for l10n checkins.
If you want to lockdown the repository in the future, then please try to
coordinate this with me beforehand, if you want calendar to be part of
the lockdown.
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Axel Hecht
> Axel Hecht wrote:
>
>> Hi all,
>>
>> as announced previously, we're locking down the l10n rep for Beta 5 now.
>
> Since when do you have the authority to lockdown the whole l10n
> repository just for one single application? Did I miss the "Firefox
> Superiority" post here or elsewhere?
>
> As far as I'm concerned (and I'm speaking for the Calendar Project here)
> calendar is still open and will stay open for l10n checkins.
>
> If you want to lockdown the repository in the future, then please try to
> coordinate this with me beforehand, if you want calendar to be part of
> the lockdown.
>
> Simon
I didn't, the Firefox release team did. Take this up with beltzner?
Axel
Robert Kaiser
> Rimas Kudelis wrote:
>> Hi Axel,
>>
>> is mail/ also locked?
>
> I'd rather see you not check in to mail or suite. That's as rude as I get.
>
> Is there a lot going on there?
There may be at any time, as the main CVS tree is in no way restricted
for those at the moment.
So I hope such times where you want everything in l10n/ closed are kept
down to one or two days at max at any time in any development cycle.
Robert Kaiser
Axel Hecht
If you guys have suggestions, or even patches, on how to close down just
one app, I'm all ears. I haven't come up with something that doesn't suck.
Axel
Robert Kaiser
> If you guys have suggestions, or even patches, on how to close down just
> one app, I'm all ears. I haven't come up with something that doesn't suck.
I don't yet know the problem you have with checkins going into the L10n
repository - on the main CVS tree there seems to be no problem with
checkins going on in non-Firefox directories while a FF freeze is going on.
Robert Kaiser
Damjan Georgievski
>>> up on that later, when we know more. Something in the order of 2-3 weeks
>>> until RC1 freeze date, though.
>>
>> Do you expect there'll be a landing window for l10n after RC1?
>> Or the 2-3 weeks after b5 will be the last?
>
> An RC is a release candidate. There shouldn't be any scheduled work to
> happen after RC1.
yeah but a code freeze and l10n freeze is not the same thing...
You can't realistically test all of the l10n with non-finished code!
The thing is, I expect to have much more testers with the RC1 release, so
that will surrely mean much more input on the l10n front too.
--
damjan
Simon Paquet
I raised this issue in mozilla.dev.planning. Here's Mike Shaver's take on
the situation:
|Message-ID: <mailman.144.12061149...@lists.mozilla.org>
|From: "Mike Shaver" <mike....@gmail.com>
|Subject: Re: Tree locking down tonight for Beta 5 bake-off!
|
|On Fri, Mar 21, 2008 at 11:06 AM, Simon Paquet <si...@gmx.de> wrote:
|> |I didn't, the Firefox release team did. Take this up with beltzner?
|>
|> If I read something into this, that's clearly not there, then please tell
|> me, but for me, this sounds an awful lot like "Tree is closed. Period."
|> And this message seems to come (according to Axel) from the Firefox
|> release team and not from him personally.
|
|I am 100% certain that Beltzner has the same position on this that I
|do. We release drivers must have erred and miscommunicated to Axel,
|for which I apologize (to him and you, and to localizers
|inconvenienced by the misunderstanding).
|
|Please localize and develop and commit to your hearts' content in
|non-Firefox code -- subject to whatever strictures may be place for
|other apps, of course!
So, the lockdown does only affect strings for Firefox (e.g. browser,
toolkit, dom, netwerk, security, dom).
It does not affect the other apps, so strings for calendar, suite, mail
or mailnews can be changed by localizers.
Axel Hecht
If there are tricks with which we can get you more coverage and exposure
on B5, and thus testers, we should use those.
The RC is going to be an RC, and unless you come back to us with
"please, please, that's embarrassing, don't ship", we'd want to take it
from the point of view that we'd be able to ship it. The "don't ship"
would mean that we'd either have to have another cycle of l10n builds on
3.0, which is hard, or wait for 3.0.1, or whatever it's called.
Axel
Damjan Georgievski
>> that will surrely mean much more input on the l10n front too.
>
> If there are tricks with which we can get you more coverage and exposure
> on B5, and thus testers, we should use those.
I don't know af any.
Anyway, at least you (mozilla, whoever) should make sure l10n checkins would
be imidiatelly allowed for 3.0.1. This was a problem with 2.0 when l10n
updates were not allowed for some time after 2.0 shipped. KDE and Gnome
follow this practice for ex. After a major release there's a .1 release
that mostly updates l10n.
--
damjan
Axel Hecht
I don't really mind what KDE and Gnome do. To me, an open tree implies
an opt-in for the following milestone/release. Our dot releases are for
security and stability, and I don't see us taking any chances in opening
the tree and then not being able to push out a security update.
This goes by the same argument that I gave in my reply to Cedric's post,
we just can't tell if something's broken or not by just looking at
tinderbox. I'm not a great friend of those approvals myself, as it's me
who's doing them. But I do find bugs in the patches, so it's not just an
academic thing.
From another point of view, we're shipping the 5th localized milestone
in a bit for some of our languages. Granted, the first for Mongolian.
If you, or others, think that your 3.0 final release will receive a
significant amount of feedback and changes for 3.0.1, maybe we should
open the discussion on whether to release all languages that are green
as final localizations, or if we should add some set of languages as
Beta. I'm not picking on Mongolian here, but there are a bunch of other
languages in CVS that are shipping for the first time, or haven't
shipped yet at all. We do label some languages Beta on the stable
branch, I would think that we could do so for Fx3.0, too.
Axel
Damjan Georgievski
maybe you need to mind... obviously they solved some problems that Mozilla
is strugling with. Please don't dismiss them.
> To me, an open tree implies
> an opt-in for the following milestone/release. Our dot releases are for
> security and stability, and I don't see us taking any chances in opening
> the tree and then not being able to push out a security update.
Why would l10n block security updates?
> This goes by the same argument that I gave in my reply to Cedric's post,
> we just can't tell if something's broken or not by just looking at
> tinderbox. I'm not a great friend of those approvals myself, as it's me
> who's doing them. But I do find bugs in the patches, so it's not just an
> academic thing.
The way I see it.. this implies that the mozilla processes or infrastructure
or technology is broken here.
L10n should in no way affect the workability of the browser.
(of course changed words might confuse the user, but the l10n people are
aware of that - I'm talking about stupid "yellow screen of death" problems
or charset conversions in the windows installer).
> From another point of view, we're shipping the 5th localized milestone
> in a bit for some of our languages. Granted, the first for Mongolian.
>
> If you, or others, think that your 3.0 final release will receive a
> significant amount of feedback and changes for 3.0.1, maybe we should
> open the discussion on whether to release all languages that are green
> as final localizations, or if we should add some set of languages as
> Beta.
label it Beta .. and we receive a lot less testing
--
damjan
Axel Hecht
>> I don't really mind what KDE and Gnome do.
>
> maybe you need to mind... obviously they solved some problems that Mozilla
> is strugling with. Please don't dismiss them.
>
>> To me, an open tree implies
>> an opt-in for the following milestone/release. Our dot releases are for
>> security and stability, and I don't see us taking any chances in opening
>> the tree and then not being able to push out a security update.
>
> Why would l10n block security updates?
What else?
>> This goes by the same argument that I gave in my reply to Cedric's post,
>> we just can't tell if something's broken or not by just looking at
>> tinderbox. I'm not a great friend of those approvals myself, as it's me
>> who's doing them. But I do find bugs in the patches, so it's not just an
>> academic thing.
>
> The way I see it.. this implies that the mozilla processes or infrastructure
> or technology is broken here.
>
> L10n should in no way affect the workability of the browser.
> (of course changed words might confuse the user, but the l10n people are
> aware of that - I'm talking about stupid "yellow screen of death" problems
> or charset conversions in the windows installer).
Duh. Or do you expect me to say more?
>
>> From another point of view, we're shipping the 5th localized milestone
>> in a bit for some of our languages. Granted, the first for Mongolian.
>>
>> If you, or others, think that your 3.0 final release will receive a
>> significant amount of feedback and changes for 3.0.1, maybe we should
>> open the discussion on whether to release all languages that are green
>> as final localizations, or if we should add some set of languages as
>> Beta.
>
> label it Beta .. and we receive a lot less testing
>
I'll try to get numbers about the current testers on fx3 and users on 2,
maybe that'll help.
Anyway, your points are moot, we're a few weeks to release and you
phantasise about how the world could be. That's just not relevant to the
issues at hand.
Axel
Damjan Georgievski
> phantasise about how the world could be. That's just not relevant to the
> issues at hand.
We had contentions like this in the 2.0 release too. Nothing changed .. Now
we are in the same situation.
What do you expect me to do? Just not say anything?
The problems will not go away.
--
damjan
Rimas Kudelis
Hmm... Confronting each other will not solve your problems either.
IMHO, if you expect many testers for RC1, that's great. And if you're
afraid you won't be able to land any changes post RC1, you shouldn't.
There always are bugs, here and there, and that's what Bugzilla is for.
When you have changes you want to incorporate past any release (be that
an RC or x.x.x) you have to simply file a bug (or a few of them) for
your localization component. I'm not sure how Axel would react to some
major change, but I'm sure that at least fixes for true bugs (such as
missed %s, or maybe even grammar mistakes) would get a check-in approval.
RQ
Simon Paquet
> This goes by the same argument that I gave in my reply to Cedric's
> post, we just can't tell if something's broken or not by just looking
> at tinderbox. I'm not a great friend of those approvals myself, as
> it's me who's doing them. But I do find bugs in the patches, so it's
> not just an academic thing.
It doesn't affect me really, but I'm really wondering why you need so
much process around this issue?
I understand the necessity of approvals when it comes to trademarked
content, default bookmarks and search engines, but why on earth do you
need to approve typo fixes, fixes for broken line-ends, etc.?
Granted, the calendar apps are much smaller in terms of community
outreach, but a loose approach has worked well for us, even though I
would guess, that we're not getting as much quality control from
localizers as Firefox gets, it being the premier app.
Axel Hecht
> Axel Hecht wrote on 25. Mar 2008:
>
>> This goes by the same argument that I gave in my reply to Cedric's
>> post, we just can't tell if something's broken or not by just looking
>> at tinderbox. I'm not a great friend of those approvals myself, as
>> it's me who's doing them. But I do find bugs in the patches, so it's
>> not just an academic thing.
>
> It doesn't affect me really, but I'm really wondering why you need so
> much process around this issue?
>
> I understand the necessity of approvals when it comes to trademarked
> content, default bookmarks and search engines, but why on earth do you
> need to approve typo fixes, fixes for broken line-ends, etc.?
>
> Granted, the calendar apps are much smaller in terms of community
> outreach, but a loose approach has worked well for us, even though I
> would guess, that we're not getting as much quality control from
> localizers as Firefox gets, it being the premier app.
>
> Simon
>
So what happens if a localizer breaks the build? Uses a wrong %d in a
properties file so that the build crashes on use?
Should we ship that as a security and stability update to a few 10
million users?
Just asking.
Axel
Simon Paquet
>> I understand the necessity of approvals when it comes to
>> trademarked content, default bookmarks and search engines,
>> but why on earth do you need to approve typo fixes, fixes
>> for broken line-ends, etc.?
>>
>> Granted, the calendar apps are much smaller in terms of community
>> outreach, but a loose approach has worked well for us, even though
>> I would guess, that we're not getting as much quality control from
>> localizers as Firefox gets, it being the premier app.
>
> So what happens if a localizer breaks the build? Uses a wrong %d in a
> properties file so that the build crashes on use?
>
> Should we ship that as a security and stability update to a few 10
> million users?
That's the tradeoff you might have to make.
What is more important, the chance that a bad change might break a
release build or a happy localizer that is actively working on his
localization and fixes known issues fast?
In the end it comes down to two basic risk management questions?
- What is the probability of a bad change late in a release cycle or
in a security release cycle?
- What is the impact of that change?
Once you have the answers for these two questions, you'll have to
determine what the ratio of bad changes, which break the build
compared to all bad changes (incl. typos, bad line-ends, etc.) is.
Only then are you able to make an informed decision.
Correct me if I'm wrong, but AFAIK this informed decision-making
process hasn't happened yet. So right now, you're basically working
on a "it has happened in the past, so it will happen in the
future"-assumption, thereby burdening all Firefox localizers with
the additional process requirements.
For Calendar, we have been giving localizers the benefit of doubt
and so far it hasn't hurt us yet.
Axel Hecht
I'm fed up that you just assume that anything that hasn't been delivered
into your personal inbox just had to be made up by me personally,
without any rationale or thinking.
Axel
Simon Paquet
>> Correct me if I'm wrong, but AFAIK this informed decision-making
>> process hasn't happened yet. So right now, you're basically working
>> on a "it has happened in the past, so it will happen in the
>> future"-assumption, thereby burdening all Firefox localizers with
>> the additional process requirements.
>
> I'm fed up that you just assume that anything that hasn't been
> delivered into your personal inbox just had to be made up by me
> personally, without any rationale or thinking.
I don't expect stuff like that to come to my personal inbox, but
I've been reading planet, your blog and this newsgroup regularly
for quite some time and haven't come across this. And looking at
what other people write, they also do not seem to have come across
this.
This may (of course) be entirely my fault, so I'm curious, where
can I read up on the rationale and thinking behind this?
Thanks