[Openstack-i18n] Consensus on translation update deadline for future stable update

Akihiro Motoki amotoki at gmail.com
Tue Dec 10 04:09:40 UTC 2013

Hi Daisy,

Please find my comments inline.

On Tue, Dec 10, 2013 at 8:03 AM, Ying Chun Guo <guoyingc at cn.ibm.com> wrote:
> Thank you for your work.
> See my comments below.
> Regards
> Ying Chun Guo (Daisy)
> Akihiro Motoki <amotoki at gmail.com> wrote on 2013/12/10 00:07:47:
>> Akihiro Motoki <amotoki at gmail.com>
>> 2013/12/10 00:07
>> To
>> "openstack-i18n at lists.openstack.org" <Openstack-i18n at lists.openstack.org>,
>> cc
>> Subject
>> [Openstack-i18n] Consensus on translation update deadline for future
>> stable update
>> As you may know, I discussed the deadline of translation import for
>> stable release update
>> with stable-maint team and we have a good consensus on it.
>> It applies to future stable maintenance updates too.
>>      For the stable maintenance updates, the deadline of translation
>> updates
>>      from I18N team is freeze+3 days.
>> It is worth documented in StableBranch wiki page.
> It's great that we get the consensus.
> What is the "freeze" day?
> How can I understand the stable release schedule?
> I'd like to understand what items need to be done after the freeze day,
> and the influence if we move translation update backward 3 days.

After "Freeze" day, backport patches without FFE request to
stable-maint list are denied to merge,
though FFE request criteria is not so high but FFE requests will be
validated by stable maint team.
>From the point of view of I18N team, most cases, there is no string
fixes in most cases
and translators can focus on completing their translations.

Everyone can know stable release schedule.
stable freeze date is usually announced on stable-maint ML.
IMO key persons in I18N team should subscribe stable-maint ML.
Also it is available on OpenStack Wiki:
but AFAIK stable-maint ML is the primary source.

>> Although it sometimes be short when considering holidays/vacations or
>> other reasons,
>> IMO 3 days is a enough period to catch up our translations because
>> stable updates
>> would not have many string updates.
> Yes, I agree.
> I just cost 15 minutes to catch up the updates in this stable release,
> because it's only a few strings in this update.
> I think the problem is how the coordinators can be notified.
> There are several mails going back and forth in the ML.
> I do wonder how many our coordinators would read. :))
> I don't know if personal emails to coordinators will work.

I don't have better idea than now. Possible ways are:
- Announcement to openstack-dev ML (if I18N list is not enough)
- Notification from Transifex

>> As a next step we should have a similar consensus for normal release.
>> The situation for normal release is different from stable updates, but
>> it is important
>> to make translation updates (I18N team work) a part of the release
>> process.
>> I believe Daisy will coordinate the discussion.
> There was a short discussion in the HK summit about translation coordination
> in Icehouse release.
> The string frozen date is not moved forward or backward, it is still same as
> feather frozen date.
> I don't think moving the string frozen date will bring any advantages.
> There are always "exceptions".
> In my mind, in a normal release, some important dates are:
> string frozen date
> RC1 release ( usually 4 weeks after)
> RC2 release ( usually 1 or 2 weeks after)
> final release
> Is it a "freeze date" in the normal release?
> I'd like to understand from your point of view
> what are the differences between normal release and stable update.

>From my past experience, actual "freeze date" is RC1.
Once RC1 is shipped, the criteria for merging becomes high,
but no big fixes including string updates tend to be merged until then.
I can't believe the official "string frozen date" works.

RC2 and further RC are decided by each project depending on bug status.
If RC1 has no bugs, RC1 wil become the final release.
Nobody knows how many RCs we have,
so I can't say when is the deadline for translation imports.

One idea is to have RC2 for translation updates even if RC1 has no bugs.
In Havana release, we had a couple of bugs and Horizon released RC2.
The translation update was done as a part of RC2.

Note that one of important items in Icehouse is to automate POT files update.
I hope some volunteers will work on it.
(Translation imports can be done manually)


>> Thanks,
>> Akihiro
>> _______________________________________________
>> Openstack-i18n mailing list
>> Openstack-i18n at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n

More information about the Openstack-i18n mailing list