New strings after 6.4 (string freeze) ...

l10n
#1

Hi, all,

commits like this one:
https://gerrit.libreoffice.org/#/c/85403/
introduce new strings. The string freeze was with the release of RC1, which
was pulled out on December 18. The mentioned commit was made on December
20. I did comment on the issue.

Programmers are not aware of the string freeze and implications of not
abiding it. How is the communication with the l10n teams handled in such
cases?

I propose two :
- setting a (rigorous) protocol in case there are urgent changes *after*
the string freeze (if there already is a protocol in place, let's write it
down, put it on wiki, get it out of the drawer and make it visible etc.);
the decision to allow such changes should involve the estimate of
additional work/overhead for the l10n teams and the number of new/updated
strings, how near the planned release date is etc., the persons deciding,
required announcements on this list to make l10n happen in time;
- at the moment of release (when there is string freeze, as it happened on
December 18th 2019,
https://dev-builds.libreoffice.org/pre-releases/src/?C=M&O=D) post an
automated message on the developers' list (it can be same text, just the
dates and release/code version updated) and maybe a notification on gerrit,
if possible?; it notifies coders that string freeze for X.Y (RC1) is in
effect, and mentions/links to the only way a new string can be introduced -
the protocol mentioned in the above step; also the term "string freeze"
should be explained.

Obviously even senior coders are not aware what this means for l10n teams
and the rules are really not that clear.

Thanks,
Martin

#2

Hi Martin,

Hi, all,

commits like this one:
https://gerrit.libreoffice.org/#/c/85403/
introduce new strings. The string freeze was with the release of RC1, which
was pulled out on December 18. The mentioned commit was made on December
20. I did comment on the issue.

Programmers are not aware of the string freeze and implications of not
abiding it. How is the communication with the l10n teams handled in such
cases?

This is said during the ESC call each week, commit reviews and freezes
are notified.
For this case, it was ambiguous as string freeze is noted on a week and
not a day, it was made the first day of the freeze week and was an
important fix to my eyes.
When it's out of the period, I'm asked by developers. If it's only
cosmetic then I disagree with braking the freeze.
So the communication is handled and the freeze usually well respected,
but as you see, sometimes braking it is justified and it's only and
remains an exception to the rule.

Cheers
Sophie

#3

Ok, Sophie,

but then could you please notify l10n teams about such decisions here on
the list?

I am not working via weblate and need to be informed for further actions
needed.

Furthermore in this case the deceloper thought the string freeze goes in
effect end of the week, regardless of the day of rc1 release...

Thanks, m.

V pon., 23. dec. 2019 10:52 je oseba sophi <sophi@libreoffice.org> napisala:

#4

Hi Martin,

Ok, Sophie,

but then could you please notify l10n teams about such decisions here on
the list?

I am not working via weblate and need to be informed for further actions
needed.

ok, I'll do

Furthermore in this case the deceloper thought the string freeze goes in
effect end of the week, regardless of the day of rc1 release...

yes, sorry for that. When we know a late change could happen, then the
strings are committed before like here:
https://gerrit.libreoffice.org/#/c/83453/
but sometimes it's not so easy to coordinate everything.
Cheers
Sophie