Thunderbird 3 beta3 followup

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Thunderbird 3 beta3 followup

Simon Paquet-2
Hey guys,

now that the first release candidate builds are out for beta3 are out
and that beta3 will hopefully be released tomorrow I wanted to use the
opportunity to gather some feedback from you on what was good and bad
with the beta3 release.

I have some items on the list myself, but would appreciate it if you
could add some more stuff there, if you think it is important.

What went well:
- 43 locales opted in
  I think it was great that we got as many locales as with beta2, even
  though the string freeze was announced pretty late and the opt-in
  thread even later
- Pretty smooth opt-in period
  Compared with b1 and b2, it seemed to me that a lot less questions
  were raised indicating a lot more familiarity with the TB release
  process from the localizer side

What went not so well:
- We lost four locales (bg, he, pt-PT and sr) compared with beta2
  I'm not really sure, why that happened. A few ideas come to my mind:
  holiday season, burnout after the Firefox 3.5 release, very long
  period between b2 and b3 pushing the consideration of Thunderbird
  well to the back of the localizers mind. I would appreciate it if
  you guys could comment on that.
- Communication
  We originally announced the b3 schedule back in mid-April, then
  said that it would take some more time and basically kept quiet
  until the end of June. That was far from optimal in my mind.
- Communication #2
  The release schedule and the opt-in thread were both announced pretty
  late in the cycle.
- Hardcoded autoconfig strings
  I guess that enough has been said regarding this topic, but I wanted
  to add it for the sake of completeness

Now it's your turn. I would really appreciate your feedback.

Cya
Simon

--
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog:       http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

F Wolff-2
Op Ma, 2009-07-20 om 12:39 +0200 skryf Simon Paquet:

> Hey guys,
>
> now that the first release candidate builds are out for beta3 are out
> and that beta3 will hopefully be released tomorrow I wanted to use the
> opportunity to gather some feedback from you on what was good and bad
> with the beta3 release.
>
> I have some items on the list myself, but would appreciate it if you
> could add some more stuff there, if you think it is important.
>
> What went well:
> - 43 locales opted in
>   I think it was great that we got as many locales as with beta2, even
>   though the string freeze was announced pretty late and the opt-in
>   thread even later
> - Pretty smooth opt-in period
>   Compared with b1 and b2, it seemed to me that a lot less questions
>   were raised indicating a lot more familiarity with the TB release
>   process from the localizer side
>
> What went not so well:
> - We lost four locales (bg, he, pt-PT and sr) compared with beta2
>   I'm not really sure, why that happened. A few ideas come to my mind:
>   holiday season, burnout after the Firefox 3.5 release, very long
>   period between b2 and b3 pushing the consideration of Thunderbird
>   well to the back of the localizers mind. I would appreciate it if
>   you guys could comment on that.
> - Communication
>   We originally announced the b3 schedule back in mid-April, then
>   said that it would take some more time and basically kept quiet
>   until the end of June. That was far from optimal in my mind.
> - Communication #2
>   The release schedule and the opt-in thread were both announced pretty
>   late in the cycle.
> - Hardcoded autoconfig strings
>   I guess that enough has been said regarding this topic, but I wanted
>   to add it for the sake of completeness
>
> Now it's your turn. I would really appreciate your feedback.

Hallo Simon

Not much from my side, but two small things while you are poking:

 - Two days between firm string freeze and final lockdown. This means we
have to be working on this, have time, have internet connectivity, etc.
in two days if there were changes. Since we won't know beforehand if
there will be changes, I can't count on nothing being required in those
two days. I'm sure we are all internet addicts, but sometimes I'm
travelling, sometimes we have workshops away from the city, etc.

Some projects I contribute to, measure this period in weeks. For
example, the recent pidgin freeze was announced to be _at_least_ 16
days, and an incomplete localisation is still perfectly usable (compared
to Mozilla products). I don't want this to be another discussion about
100% localisations, but the l10n technology used here means we need
longer freeze periods, since updates are mandatory. Or let's just say,
loosing languages seems expected.


 - Is there any team that doesn't want their latest revisions in hg to
be used for the releases? Is there any way we can get rid of the opt-in
process? Can we have a permanent opt-in for our latest revision in hg if
we are green?


Keep well
Friedel

--
Recently on my blog:
http://translate.org.za/blogs/friedel/en/content/firefox-35-released

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Robert Kaiser
In reply to this post by Simon Paquet-2
F Wolff wrote:
>   - Two days between firm string freeze and final lockdown.

We both, SeaMonkey and Thunderbird, need to do that differently in the
future, yes, I already mentioned that to a few people. I think it would
be good to have a firm string freeze at least 2 workdays + a weekend
before the firm code freeze - ideally we can make this period even longer.

Robert Kaiser
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Axel Hecht
In reply to this post by Simon Paquet-2
On 23.07.09 13:06, F Wolff wrote:
> Op Ma, 2009-07-20 om 12:39 +0200 skryf Simon Paquet:
<...>
>
>   - Is there any team that doesn't want their latest revisions in hg to
> be used for the releases? Is there any way we can get rid of the opt-in
> process? Can we have a permanent opt-in for our latest revision in hg if
> we are green?

Gandalf and I are working on infrastructure that's going to make this
easier. Sadly, we're learning still on what scenarios the logic needs to
cover, and each lesson we learn is coming with some intensive
rearchitecture :-(. I really hope that stops soon, as it's not helping
my life either.

Anyway, it has been discussed extensively in a few places, "green" isn't
green enough these days. We need manual testing on a variety of things,
and that's why we ship the version that you tested.

Then you can get back to work, tweak, improve, fix, test, and once an
iteration is good for public consumption on non-nightly testers, you
request a new changeset to be included in the build.

One thing that we're adding right now is a way for the release drivers
to take off all sign-offs that are obsoleted by a l110n-impact late
landing. So we could offer to do things like optimistically taking
opt-ins, and kill them with an announcement post if really something
needs localizer attention.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Simon Paquet-2
In reply to this post by Simon Paquet-2
F Wolff wrote on 23. Jul 2009:

>> Now it's your turn. I would really appreciate your feedback.
>
> Hallo Simon
>
> Not much from my side, but two small things while you are poking:
>
>  - Two days between firm string freeze and final lockdown. This
>    means we have to be working on this, have time, have internet
>    connectivity, etc. in two days if there were changes. Since we
>    won't know beforehand if there will be changes, I can't count on
>    nothing being required in those two days. I'm sure we are all
>    internet addicts, but sometimes I'm travelling, sometimes we have
>    workshops away from the city, etc.
>
>    Some projects I contribute to, measure this period in weeks. For
>    example, the recent pidgin freeze was announced to be _at_least_
>    16 days, and an incomplete localisation is still perfectly usable
>    (compared to Mozilla products). I don't want this to be another
>    discussion about 100% localisations, but the l10n technology used
>    here means we need longer freeze periods, since updates are
>    mandatory. Or let's just say, loosing languages seems expected.

Thanks for bringing this up, Friedel.

Let me respond with a two-fold answer:

1. These short periods of time between the firm string freeze and the
   l10n-repo lockdown only apply to alpha and beta releases. That is
   because we don't want to slow down the development process too much
   as alpha and beta releases are basically just snapshots of what's
   currently already developed.

   For the final release of TB3 the period between the firm string
   freeze and the l10n-repo lockdown will be much longer. Expect
   something along the lines of at least 2-4 weeks.

2. I think your post exhibits a misconception of what the various dates
   in the release process actually mean. There is a reason why we put
   the slushy string freeze 14 days before the l10n-repo lockdown.

   We want you to start localizing immediately after the slushy string
   freeze with the expectation that only a very limited number of
   strings (preferably zero) are introduced after that date. For beta3
   that was the case with only one late-l10n bug introducing three new
   strings, which was flagged as late-l10n on July 7 and fixed on the
   same day.

   So for what it is worth, in reality the period between the string
   freeze and the repo lockdown in much longer than two days. See
   also the autoconfig discussion here in this group, where we
   explicitly made the decision not to land a bunch of strings very
   late in the cycle in order to not cause localizers a lot of headache.

>  - Is there any team that doesn't want their latest revisions in hg
>    to be used for the releases? Is there any way we can get rid of
>    the opt-in process? Can we have a permanent opt-in for our latest
>    revision in hg if we are green?

I see upsides and downsides to that proposal. The most obvious downside
that I see is that you place all the responsibility (and the potential
to make errors) into the hand of one person, where currently it is much
more distributed.

Could you elaborate a little bit more on why you think the opt-in
process should be disbanded? What are your major pain points here that
should addressed and fixed?

Cya
Simon

--
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog:       http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Robert Kaiser
Simon Paquet wrote:
> So for what it is worth, in reality the period between the string
> freeze and the repo lockdown in much longer than two days.

Still, we need someone from every locale to do the opt-in during exactly
those two days (or slightly longer actually), which is unfortunate in
the holiday period as not everyone will be around all the time. nl ran
into that problem, for example.

Robert Kaiser
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Simon Paquet-2
Robert Kaiser wrote on 23. Jul 2009:

>> So for what it is worth, in reality the period between the string
>> freeze and the repo lockdown in much longer than two days.
>
> Still, we need someone from every locale to do the opt-in during
> exactly those two days (or slightly longer actually), which is
> unfortunate in the holiday period as not everyone will be around
> all the time.

Not necessarily. Nothing prevents a localizer from opting-in earlier
than the firm string freeze. Of course there's still the risk of a
late-l10n change, but that has never happened less than at least 3-4
days before the firm string freeze, which means that there would then
still be 5-6 days time to make the necessary change and opt-in again.

Simon

--
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog:       http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Michael Lefevre-2
On 23/07/2009 15:09, Simon Paquet wrote:
 > Of course there's still the risk of a
> late-l10n change, but that has never happened less than at least 3-4
> days before the firm string freeze, which means that there would then
> still be 5-6 days time to make the necessary change and opt-in again.

Just a bystander here, but if it has never happened in the past, and you
think (as it seems) the risk of it happening in future is
insignificantly small, then why not just move the freeze back 3-4 days?

Michael
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

F Wolff-2
In reply to this post by Simon Paquet-2
Op Do, 2009-07-23 om 14:08 +0200 skryf Simon Paquet:

> F Wolff wrote on 23. Jul 2009:
>
> >> Now it's your turn. I would really appreciate your feedback.
> >
> > Hallo Simon
> >
> > Not much from my side, but two small things while you are poking:
> >
> >  - Two days between firm string freeze and final lockdown. This
> >    means we have to be working on this, have time, have internet
> >    connectivity, etc. in two days if there were changes. Since we
> >    won't know beforehand if there will be changes, I can't count on
> >    nothing being required in those two days. I'm sure we are all
> >    internet addicts, but sometimes I'm travelling, sometimes we have
> >    workshops away from the city, etc.
> >
> >    Some projects I contribute to, measure this period in weeks. For
> >    example, the recent pidgin freeze was announced to be _at_least_
> >    16 days, and an incomplete localisation is still perfectly usable
> >    (compared to Mozilla products). I don't want this to be another
> >    discussion about 100% localisations, but the l10n technology used
> >    here means we need longer freeze periods, since updates are
> >    mandatory. Or let's just say, loosing languages seems expected.
>
> Thanks for bringing this up, Friedel.
>
> Let me respond with a two-fold answer:
>
> 1. These short periods of time between the firm string freeze and the
>    l10n-repo lockdown only apply to alpha and beta releases. That is
>    because we don't want to slow down the development process too much
>    as alpha and beta releases are basically just snapshots of what's
>    currently already developed.
>
>    For the final release of TB3 the period between the firm string
>    freeze and the l10n-repo lockdown will be much longer. Expect
>    something along the lines of at least 2-4 weeks.

That will be great, thank you!


> 2. I think your post exhibits a misconception of what the various dates
>    in the release process actually mean. There is a reason why we put
>    the slushy string freeze 14 days before the l10n-repo lockdown.
>
>    We want you to start localizing immediately after the slushy string
>    freeze with the expectation that only a very limited number of
>    strings (preferably zero) are introduced after that date. For beta3
>    that was the case with only one late-l10n bug introducing three new
>    strings, which was flagged as late-l10n on July 7 and fixed on the
>    same day.
>
>    So for what it is worth, in reality the period between the string
>    freeze and the repo lockdown in much longer than two days. See
>    also the autoconfig discussion here in this group, where we
>    explicitly made the decision not to land a bunch of strings very
>    late in the cycle in order to not cause localizers a lot of headache.

No, I think I understand the meaning of the dates. I really just meant
what Robert underlined: I might need to be online during a specific 48
hour period, which is an assumption with consequences. I might be able
to opt in earlier, or might not, but I don't know beforehand. So in _my_
way of thinking, the real string freeze is only 2 days, since those are
the only two days in which I have certain guarantees that I need to do
the final work (final checking, opt-in, etc). The two freeze periods
combined are probably enough time for the translation work, so my
comment is not really about that aspect.

If we can get working localisations for the beta even though late-l10n
changes were not incorporated, then things will already look much
different.


> >  - Is there any team that doesn't want their latest revisions in hg
> >    to be used for the releases? Is there any way we can get rid of
> >    the opt-in process? Can we have a permanent opt-in for our latest
> >    revision in hg if we are green?
>
> I see upsides and downsides to that proposal. The most obvious downside
> that I see is that you place all the responsibility (and the potential
> to make errors) into the hand of one person, where currently it is much
> more distributed.
>
> Could you elaborate a little bit more on why you think the opt-in
> process should be disbanded? What are your major pain points here that
> should addressed and fixed?

Bandwidth, both the human kind and the tubes kind.  From a quick search
it looks like over 500 emails this year so far relating to opt-ins on
this list. Currently we do this for 3 products, and an increasing amount
of languages (which is good :-), which takes its toll on everyone, I'm
sure. I know Mozilla expects us all to devote our whole lives to doing
this, but I am subscribed to many mailing lists for many programs, and
always looking for ways to limit the communication to the most useful
types.

Personally I have never made a commit without the intention of shipping
it, that is why I am asking how often other people commit without the
intention of it shipping. I that commits after an initial opt-in would
be improvements and during a time of strict review anyway. The critical
update of Macedonian for Firefox 3.5 was in time for the release, but
human bandwidth caused it to be missed (which is entirely
understandable), so I'd just like us to consider if the opt-in process
is really helping us to reach higher quality. I know that is the
intention, but we have at least one contra example. But...

... without knowing the details, I assume the "infrastructure" that Axel
mentioned, will simplify things (especially for you and him and
Robert :-), so wishing Gandalf and Axel well on those things.

Keep well
Friedel


--
Recently on my blog:
http://translate.org.za/blogs/friedel/en/content/firefox-35-released

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Axel Hecht
In reply to this post by Simon Paquet-2
On 23.07.09 19:34, F Wolff wrote:

> Op Do, 2009-07-23 om 14:08 +0200 skryf Simon Paquet:
>> F Wolff wrote on 23. Jul 2009:
>>
>>>> Now it's your turn. I would really appreciate your feedback.
>>>
>>> Hallo Simon
>>>
>>> Not much from my side, but two small things while you are poking:
>>>
>>>   - Two days between firm string freeze and final lockdown. This
>>>     means we have to be working on this, have time, have internet
>>>     connectivity, etc. in two days if there were changes. Since we
>>>     won't know beforehand if there will be changes, I can't count on
>>>     nothing being required in those two days. I'm sure we are all
>>>     internet addicts, but sometimes I'm travelling, sometimes we have
>>>     workshops away from the city, etc.
>>>
>>>     Some projects I contribute to, measure this period in weeks. For
>>>     example, the recent pidgin freeze was announced to be _at_least_
>>>     16 days, and an incomplete localisation is still perfectly usable
>>>     (compared to Mozilla products). I don't want this to be another
>>>     discussion about 100% localisations, but the l10n technology used
>>>     here means we need longer freeze periods, since updates are
>>>     mandatory. Or let's just say, loosing languages seems expected.
>>
>> Thanks for bringing this up, Friedel.
>>
>> Let me respond with a two-fold answer:
>>
>> 1. These short periods of time between the firm string freeze and the
>>     l10n-repo lockdown only apply to alpha and beta releases. That is
>>     because we don't want to slow down the development process too much
>>     as alpha and beta releases are basically just snapshots of what's
>>     currently already developed.
>>
>>     For the final release of TB3 the period between the firm string
>>     freeze and the l10n-repo lockdown will be much longer. Expect
>>     something along the lines of at least 2-4 weeks.
>
> That will be great, thank you!
>
>
>> 2. I think your post exhibits a misconception of what the various dates
>>     in the release process actually mean. There is a reason why we put
>>     the slushy string freeze 14 days before the l10n-repo lockdown.
>>
>>     We want you to start localizing immediately after the slushy string
>>     freeze with the expectation that only a very limited number of
>>     strings (preferably zero) are introduced after that date. For beta3
>>     that was the case with only one late-l10n bug introducing three new
>>     strings, which was flagged as late-l10n on July 7 and fixed on the
>>     same day.
>>
>>     So for what it is worth, in reality the period between the string
>>     freeze and the repo lockdown in much longer than two days. See
>>     also the autoconfig discussion here in this group, where we
>>     explicitly made the decision not to land a bunch of strings very
>>     late in the cycle in order to not cause localizers a lot of headache.
>
> No, I think I understand the meaning of the dates. I really just meant
> what Robert underlined: I might need to be online during a specific 48
> hour period, which is an assumption with consequences. I might be able
> to opt in earlier, or might not, but I don't know beforehand. So in _my_
> way of thinking, the real string freeze is only 2 days, since those are
> the only two days in which I have certain guarantees that I need to do
> the final work (final checking, opt-in, etc). The two freeze periods
> combined are probably enough time for the translation work, so my
> comment is not really about that aspect.
>
> If we can get working localisations for the beta even though late-l10n
> changes were not incorporated, then things will already look much
> different.
>
>
>>>   - Is there any team that doesn't want their latest revisions in hg
>>>     to be used for the releases? Is there any way we can get rid of
>>>     the opt-in process? Can we have a permanent opt-in for our latest
>>>     revision in hg if we are green?
>>
>> I see upsides and downsides to that proposal. The most obvious downside
>> that I see is that you place all the responsibility (and the potential
>> to make errors) into the hand of one person, where currently it is much
>> more distributed.
>>
>> Could you elaborate a little bit more on why you think the opt-in
>> process should be disbanded? What are your major pain points here that
>> should addressed and fixed?
>
> Bandwidth, both the human kind and the tubes kind.  From a quick search
> it looks like over 500 emails this year so far relating to opt-ins on
> this list. Currently we do this for 3 products, and an increasing amount
> of languages (which is good :-), which takes its toll on everyone, I'm
> sure. I know Mozilla expects us all to devote our whole lives to doing
> this, but I am subscribed to many mailing lists for many programs, and
> always looking for ways to limit the communication to the most useful
> types.
>
> Personally I have never made a commit without the intention of shipping
> it, that is why I am asking how often other people commit without the
> intention of it shipping. I that commits after an initial opt-in would
> be improvements and during a time of strict review anyway. The critical
> update of Macedonian for Firefox 3.5 was in time for the release, but
> human bandwidth caused it to be missed (which is entirely
> understandable), so I'd just like us to consider if the opt-in process
> is really helping us to reach higher quality. I know that is the
> intention, but we have at least one contra example. But...
>
> ... without knowing the details, I assume the "infrastructure" that Axel
> mentioned, will simplify things (especially for you and him and
> Robert :-), so wishing Gandalf and Axel well on those things.

Thanks.

And yes, sadly we still find issues during reviews. We still have bugs
in some of the tools out there, some people are just confused, and it's
generally a good idea to check in on stuff.

What we try to do with the sign-off app are a few things:

- take out the single point of failure of the one that collects the
source stamps (sorry Damjan)
- reduce the noise on the list around releases
- be more flexible in which source stamps to take
- be more flexible in when to start taking opt-ins
- empower the build guys to actually work off of the same data that the
l10n drivers are
- open the door to present the results of more tests at sign-off
- lower the chances of error, like handing in an l10n-central source
stamp or such
- keep the flexibility we have on the hg repos now for ongoing
development while still being able to ship zero-days ad-hoc in all our
languages

We're making good progress, and I locally already use a rather old
version of our code to keep track of the sign-offs. Sadly, as the diff
code is so much better on the current state, but I didn't dare to
migrate my existing data just yet.

We have plans beyond that, but let me refrain from wetting your
appetite, as we're still struggling with just the basics like what we
need to do to get ldap auth enabled for a site that gandalf and I hack
on etc.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Simon Paquet-3
In reply to this post by Michael Lefevre-2
Michael Lefevre wrote:

>> Of course there's still the risk of a
>> late-l10n change, but that has never happened less than at least 3-4
>> days before the firm string freeze, which means that there would then
>> still be 5-6 days time to make the necessary change and opt-in again.
>
>Just a bystander here, but if it has never happened in the past, and you
>think (as it seems) the risk of it happening in future is
>insignificantly small, then why not just move the freeze back 3-4 days?

Because it's good to have some kind of buffer zone and because my main
argument still is, that this tight schedule just applies to alpha and
beta releases, not to final releases.

Simon Paquet
--
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog:       http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.calendar-project.org
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Axel Hecht
On 23.07.09 22:54, Simon Paquet wrote:

> Michael Lefevre wrote:
>
>>> Of course there's still the risk of a
>>> late-l10n change, but that has never happened less than at least 3-4
>>> days before the firm string freeze, which means that there would then
>>> still be 5-6 days time to make the necessary change and opt-in again.
>>
>> Just a bystander here, but if it has never happened in the past, and you
>> think (as it seems) the risk of it happening in future is
>> insignificantly small, then why not just move the freeze back 3-4 days?
>
> Because it's good to have some kind of buffer zone and because my main
> argument still is, that this tight schedule just applies to alpha and
> beta releases, not to final releases.

The other thing I'd like to add to the discussion is this:

We're always tempted to think along the lines of "how bad could it be to
just add N days to fix this problem".

The real problem is, all of the participants in a release think that
way. And for those driving the release, it's a matter of fighting human
nature and just do whatever it takes to stick to a deadline at some point.

This is also a bit of a growth problem. Back in the days when all folks
you could blame for slipping a milestone were in one room, and you could
physically harass them, the tendency to abuse a bit of slack was much
lower than in the current size, at least for fx development.

We just need to be paranoid about each day. It's somewhat ridiculous for
each individual day, but you gotta count at some point, and count hard.

My personal input to the maildev team would still be to be less focused
on fuzzy, and turn more towards "strict" deadlines with plenty of room
for l10n, with some acknowledgment that disasters can happen and need to
be dealt with then on a case by case basis. As in reality, any code
freeze, l10n or c++, is subject to better knowledge at the time when the
code is actually there.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Cédric Corazza
Le 24/07/2009 00:59, Axel Hecht a écrit :
> We just need to be paranoid about each day. It's somewhat ridiculous for
> each individual day, but you gotta count at some point, and count hard.
>
> My personal input to the maildev team would still be to be less focused
> on fuzzy, and turn more towards "strict" deadlines with plenty of room
> for l10n, with some acknowledgment that disasters can happen and need to
> be dealt with then on a case by case basis. As in reality, any code
> freeze, l10n or c++, is subject to better knowledge at the time when the
> code is actually there.

As a localizer, I do agree with Axel's statement. We had recently to
move to Mercurial, to move to the opt-in thread for release, some sites
appear to be localized, though not mandatory, but most wanted for some
locales, etc.
We do need firm dates and enough time to localize and test before release.

We will have soon or later to localize http://www.mozillamessaging.com 
site, so please, start this process as soon as possible, at least for
the most static pages,and to make the l10n process common to everyone.

My two cents

Cédric
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Thunderbird 3 beta3 followup

Filip Miletic-4
In reply to this post by Simon Paquet-2
Op 23-07-09 04:06, F Wolff schreef:
>> What went not so well:
>> - We lost four locales (bg, he, pt-PT and sr) compared with beta2
>>    I'm not really sure, why that happened. A few ideas come to my mind:

I can speak for sr here.  Sorry, but personal matters interfered,
combined with the rather short time allotted for updating the
translations.  I will bring sr up to speed as soon as I can.

f
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n