24 hour /l10n repository lock down starting Monday, Dec 10th, 8am UTC
Axel Hecht
we ran into some confusion about how to build Firefox 3 B2 l10n, I'd
like to lock down the /l10n repository for 24 hours starting Monday, Dec
10th, 8am UTC.
Things are pretty confused right now, so I'd like to see this apply for
not just Firefox, but the complete rep, including seamonkey,
thunderbird, calendar.
I'd marshal some bustage fixes in, please catch me on irc on #l10n.
I understand that this is somewhat of a drastic measure, and something
that we usually don't do, but this time around, I'd rather do it.
Axel
Robert Kaiser
> we ran into some confusion about how to build Firefox 3 B2 l10n, I'd
> like to lock down the /l10n repository for 24 hours starting Monday, Dec
> 10th, 8am UTC.
>
> Things are pretty confused right now, so I'd like to see this apply for
> not just Firefox, but the complete rep, including seamonkey,
> thunderbird, calendar.
I hope you can ensure then that no string changes in en-US are landed
for any app in our repository, I'd hate to see trees turn orange/red
without any allowance to correct that.
Robert Kaiser
Axel Hecht
Nothing but fx3 b2 is really time critical here, so I don't really think
that's a priority. I agree that it'd be nice if we wouldn't have to, but
given the current confusion, I just don't think it's reasonable to not
close the /l10n tree. Given how fuzzily the en-US tree is documented
right now, I'm not making any calls on that one.
Axel
Robert Kaiser
> Nothing but fx3 b2 is really time critical here, so I don't really think
> that's a priority.
Sorry, but I see green builds as a priority at all times, even if it's
only something seemingly useless in MoCo eyes like a L10n build of
SeaMonkey.
Robert Kaiser
Axel Hecht
Sorry, I'll overrule that for Monday.
Axel
Robert Kaiser
Wow, Firefox decides that it's important, potentially breaks processes
of other people and does not even notify affected developers in their
channels (like, say, the few dev newsgroups of projects that use trunk
L10n CVS). I guess I should stop talking to people like Firefox
development would be a friendly place.
Robert Kaiser
Ricardo Palomares Martinez
> Hi all,
>
> we ran into some confusion about how to build Firefox 3 B2 l10n, I'd
> like to lock down the /l10n repository for 24 hours starting Monday, Dec
> 10th, 8am UTC.
I've seen this message:
http://groups.google.es/group/mozilla.dev.planning/msg/178fdff7031e8515?hl=es
I know Mike is talking about main repository, not l10n but, anyway,
does that affect anyway l10n lockdown?
> I understand that this is somewhat of a drastic measure, and something
> that we usually don't do, but this time around, I'd rather do it.
Without entering into conflicts, I guess "we usually don't do" is
rather a wish than a purpose, because the same exact problem happened
last year with a Fx2 beta lockdown in the beginning of October,
conflicting with a Calendar release schedule (and, that time too, the
entire l10n tree was lockdown).
What I mean is that maybe there is no actually a reasonable way to
manage this kind of things without locking down the entire tree, and
thus an actual policy should be in place to warn the other projects in
advance to (at least) let them reschedule their own dates. Clear rules
help to avoid conflicts. :-)
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Axel Hecht
Pfff. Not going here.
Axel
Axel Hecht
We're going to lock down the l10n much later than in fx2, at least
that's the plan. I have no idea if we actually made a call on branching
yet either, en-US or l10n.
If somebody can come up with a tool that helps manage these things more
efficiently, I'm all for it, but I haven't come up with anything. I
don't have the cycles to do so either.
As we're moving close to the end of the tree closure, we had 3
violations, 1 slippage, and 3 fixes (including joao, permission on
#l10n). This is for dead-on simple rules. As a data point, without
putting too much personal blame on Koen, but this is what he said:
> I checked the tree (http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8-l10n-nl)
> and it was written: OPEN.
That's the branch nl tinderbox, for what it's worth.
We need to get some sort of lock down for what we're building, and the
expectations clearly don't match up here.
If someone has suggestions on how this is supposed to work for non-fx
projects while we're releasing Firefox 3 is a good subject for
.planning, I'd expect the leads of the affected projects to come up with
suggestions, though.
Axel