Open Stack

Hi Daisy,

Thanks for the feeback. Please find my comments inline.
Perhaps I am just raising a question whether the string freeze works
effectively for *all* projects.

2015-06-05 15:35 GMT+09:00 Ying Chun Guo <guoyingc at cn.ibm.com>:

> Akihiro Motoki <amotoki at gmail.com> wrote on 2015/06/03 23:25:47:
>
> > From: Akihiro Motoki <amotoki at gmail.com>
> > To: "openstack-i18n at lists.openstack.org" <
> Openstack-i18n at lists.openstack.org>
> > Date: 2015/06/03 23:26
> > Subject: [Openstack-i18n] Thought on String Freeze
> >
> > Hi I18N folks,
>
> > # Congratulation for the official I18N project!!
> >
> > I first thought to send this mail to the dev list, but it seems better
> > to share my thought in the I18N folks first.
>
> > Problems
> > ==========
> >
> > I am feeling that String Freeze does not work well in the past
> > several releases.There are several
> > I think we should not apply String Freeze for projects for which not
> > so many translators work on.
> >
> > As far as I understand, Horizon and documentations are targets
> > for most translations in the past several releases.
> > On the other hands, core reviewers of projects other than Horizon and
> docs
> > (including keystone) were taking care of String Freeze exception WELL.
>
> Thank you for bringing this topic under discussion.
>
> Translation team focus on Horizon and document.
> It is true for now. But maybe in the future, it is not true.
> You never know some time translation team may decide to translate other
> projects.
> You don't know whether there is another group of team (not community
> translation team )
> who are translating them.
>
You are right to some extent, but I would like to point out that "String
Freeze"
only applies to the release critical period.
If some team catches up its translation after the release, it is not
related.
I am not sure if we need to care translations which are not synced with
OpenStack upstream releases.

Under the "big tent" model, we have more and more projects.
If we don't have translations for most of projects, there is no reason
we request them to apply "string freeze" as a result.
How can translation teams scale? If translation teams do not scale
in the near term, doesn't it sound reasonable that we prevent
non-interested project
(from translation perspective) from merging changes freely?
This is the background I proposed to declare *interested* project.

> "String freeze" is there when translation team were not set up.
> I don't like treating some projects differently just because
> translation team don't translate them now.
>
> Do you think handling String Freeze exception is a burden ?
> I remember String Freeze exception emails are sent automatically,
> if developers add a tag to the patch.
>
>From my experience, it is not a big burden but as a project reviewer
if we can know we don't need to take care of string changes in RC phases
it would be great. We sometimes put -1 only due to string changes,
but no translations actually come in. As a result, taking care of string
changes
turns out useless efforts as a result. (Honestly I approved several patches
with string changes because we didn't see any translation efforts in the
project).
Core reviewers in every project need to take care of all things before
approving patches,
but they have limited times and would like to spend their time on useful
things,
so it would be great if we can know "string freeze is effective in our
project
and it is useful".

The all above comes from the point of project core reviewers,
but I think it is worth considered.

I am exploring if I18N community can make active feedbacks
so that the whole dev commuty works efficiently
(rather than just waiting passive response),
and just raising a question from the other side
(not as I18N team but a core reviewer of several projects).

Thanks,
Akihiro


>
> Thoughts ?
>
> > My Proposal
> > =============
>
> > Considering the current status, I think we should limit "String Freeze"
> > only to projects which translators are interested in.
> > My idea is to declare projects we would like to enable "String Freeze"
> > just after Liberty-3 is cut.
> > By doing so, other projects no longer need to take care of String
> > Freeze exception.
>
> > (Note that the freeze date of the documentation projects are different
> and
> > we can apply some different policy on documentations).
> >
> > Thought?
> > I cannot join the team meeting tomorrow due to LinuxCon/CloudOpen Japan,
> > but I hope you will share your thought on this topic.
>
> > Thanks,
> > Akihiro
> > _______________________________________________
> > Openstack-i18n mailing list
> > Openstack-i18n at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-i18n/attachments/20150616/a3bbd4f9/attachment.html>