After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757792 - Unfreeze inactive translations automatically after a 1-year timeout or on minor version update?
Unfreeze inactive translations automatically after a 1-year timeout or on min...
Status: RESOLVED WONTFIX
Product: damned-lies
Classification: Infrastructure
Component: l10n.gnome.org
unspecified
Other All
: Normal major
: ---
Assigned To: damned-lies Maintainer(s)
damned-lies Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-11-08 21:42 UTC by Mingye Wang
Modified: 2015-11-09 04:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mingye Wang 2015-11-08 21:42:27 UTC
Some translations, like [GTK+ UI master in zh_CN] has been reserved for a long time, sometimes with multiple major upstream version bumps (e.g. GTK+ 3.14 -> 3.20.) This (especially for master branches) blocks new collaborations from coming in, and it looks like a good idea to clean them up.

I have two possible proposals for such automatic unlocking:

1. Unlock a master translation after 1 year of inactivity. The actual time
  may be determined by something like (mean release cycle + 1 month).
2. Unlock a master translation after a minor update release. Here minor update
  release is defined as a bump in major or minor number in a given git tag
  version `major.minor.patch`.

[GTK+ UI master in zh_CN]:https://l10n.gnome.org/vertimus/gtk+/master/po/zh_CN

// worse story: the zh_CN team coord is in the inactive members list
Comment 1 Mingye Wang 2015-11-08 21:59:32 UTC
Let's add a more neutral solution B. An alternative solution might be archiving all the states of master to the corresponding frozen version branch, like GTK-master -> GTK-3-14 when 3-16 comes out.
Comment 2 Claude Paroz 2015-11-08 22:03:25 UTC
I'm very reluctant to do any automatic unlocking here. I know that in some teams for example, locking (reserve) a translation is a mean to attribute some modules to the same person over time. Even if it's not the recommended use case, we should respect it.

I think that's the coordinator's role to arbitrate such issues. So in your specific case, if the coordinator is inactive, you should write to the gnome-i18n mailing list (with coordinator CC'd) asking for a coordinator change.

Feel free to discuss the case on the mailing list, and reopen if you find some consensus about a technical proposal to solve this issue.
Comment 3 Mingye Wang 2015-11-08 22:40:53 UTC
I think solution B may be still worth considering, possibly as an optional setting adjustable by the coordinator.

I will try to figure out a nice recommendation for a new coordinator.
Comment 4 Mingye Wang 2015-11-09 04:07:02 UTC
Mails sent to gnome-i18n list.

* zh_CN team problem: https://mail.gnome.org/archives/gnome-i18n/2015-November/msg00002.html
* technical solution: https://mail.gnome.org/archives/gnome-i18n/2015-November/msg00005.html