On 9/9/2016 1:58 PM, Ben Swartzlander wrote:
On 09/08/2016 08:37 PM, Matt Riedemann wrote:
On 9/8/2016 7:05 PM, Ravi, Goutham wrote:
Hi,
I was looking for some clarity around backports of bug fixes that
qualify the stable branch policy [1].
<http://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes>
What is the policy if the fix introduces a new translatable string or
modifies an existing one?
The guidelines in Release management [2]
<http://docs.openstack.org/project-team-guide/release-management.html>
regarding string freeze do not specifically call this scenario out. I
see that while translatable strings are mostly avoided, some projects
have been merging changes to stable branches with introduction of new
translatable strings.
The question is reminiscent of one posed in the ML a few releases ago
[3];
<http://lists.openstack.org/pipermail/openstack-dev/2015-September/073942.html>
but applies to stable branches. Should we allow changes to translatable
strings for bug fixes that matter, or is it better to always deny them
for the sake of translation accuracy?
The former IMO, a high severity bug fix trumps a translation. Note that
some projects are translated on the stable branches too, I know this is
the case for Nova.
If it's a user-facing change, like an error message in the API, then it
might require a bit more careful consideration, but if it's just a log
message marked for translation that an end user of the API wouldn't see
anyway, then I think it's fine to backport it.
So this stance makes sense to me, but I can't reconcile it with the
"hard string freeze" rules. Is the theory that after we release, the
string freeze ends for the stable branch, and that the hard string
freeze only exists for that 3 week period between RC1 and final release,
or is the theory that hard string freeze is always subject to exceptions
for "critical" bug fixes?
-Ben Swartzlander
[1]
http://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes
[2] http://docs.openstack.org/project-team-guide/release-management.html
[3]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073942.html
Thanks,
Goutham
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I treat it as the former.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
