Re: [OpenStack-I18n] [openstack-dev] [Cinder] string freeze exception for VMAX driver
Hello Helen, Thanks a lot for sharing a string freeze exception request to openstack-dev mailing list. With @amotoki's comment [1] and the discussion on the last IRC meeting yesterday [2], I18n team is fine and there will be no problem to accept the requests from I18n team's perspective. Note that String Freeze has been important for Docs & I18n team to acknowledge string freeze status and take appropriate actions of what needs to be changed to documentation and translation activities if needed. Since I18n team now more focuses on dashboard translations [1] and documents are being migrated [3], I think the importance of string freeze for server projects (e.g., cinder, nova, keystone, neutron) might be less important than previous cycle(s), but sharing the status to all the teams including release management team is a good idea to stay on the same page as much as possible :) With many thanks, /Ian, I18n team Ocata PTL. [1] http://lists.openstack.org/pipermail/openstack-i18n/2017-August/002999.html [2] http://eavesdrop.openstack.org/meetings/openstack_i18n_meeting/2017/openstac... [3] http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migrat... Walsh, Helen wrote on 8/3/2017 5:21 PM:
*To whom it may concern,*
I would like to request a string freeze exception for 2 patches that are on the merge queue for Pike.
1.VMAX driver - align VMAX QOS settings with front end (CI Passed)
https://review.openstack.org/#/c/484885/7/cinder/volume/drivers/dell_emc/vma... line 800 (removal of exception message)
Although it’s primary aim is to align QoS with front end setting it indirectly fixes a lazy loading error we were seeing around QoS which occasionally
Broke CI on previous patches.
2.VMAX driver - seamless upgrade from SMI-S to REST (CI Pending)
https://review.openstack.org/#/c/482138/19/cinder/volume/drivers/dell_emc/vm... line 1400 ,1455 (message changes)
This is vital for as reuse of volumes from Ocata to Pike. In Ocata we used SMIS to interface with the VMAX, in Pike we are using REST. A few changes needed to be made to make this transition as seamless as possible.
Thank you,
Helen
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think the importance of string freeze for server projects (e.g., cinder, nova, keystone, neutron) might be less important than previous cycle(s), but sharing the status to all the teams including release management team is a good idea to stay on the same page as much as possible :)
Hey Ian, Do you think we should make any changes to our policy for this? Just one thing that comes to mind, for server projects should we just send out a ML post with something like "Here is a list of patches we deemed important that had string translations". Just thinking of how we can keep things moving when needed while still making sure important things are communicated well. Or is that even too much? During soft string freeze, should the server project core teams just try to be more aware of these but just approve patches that are important fixes and move on? Thanks, Sean
Hello Sean, For soft string freezes as a translator's view, trying the way you suggested for server projects would be good assuming that: - The volume of changes (e.g., the number of sentences, ratio of changes) needs to be properly limited - The string change needs to be well notified to translators (e.g., sharing to openstack-i18n mailing list) - It would be so nice if I18n team can keep track of original string changes in Zanata - translate.openstack.org but currently it is not easy unfortunately. For hard string freezes, in my honest opinion, it is difficult to change the current policy because some translation sync support activities for a stable branch in openstack-infra [1] and addition of a stable version in translate.openstack.org [2] are dealt. From those views, I would like to discuss more opinions and would we try better approach from the next development cycle with agreement for server projects? With many thanks, /Ian [1] https://review.openstack.org/#/c/435812/1/jenkins/jobs/projects.yaml@1146 [2] https://translate.openstack.org/iteration/view/cinder/stable-ocata Sean McGinnis wrote on 8/5/2017 1:42 AM:
I think the importance of string freeze for server projects (e.g., cinder, nova, keystone, neutron) might be less important than previous cycle(s), but sharing the status to all the teams including release management team is a good idea to stay on the same page as much as possible :)
Hey Ian,
Do you think we should make any changes to our policy for this? Just one thing that comes to mind, for server projects should we just send out a ML post with something like "Here is a list of patches we deemed important that had string translations".
Just thinking of how we can keep things moving when needed while still making sure important things are communicated well.
Or is that even too much? During soft string freeze, should the server project core teams just try to be more aware of these but just approve patches that are important fixes and move on?
Thanks, Sean
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Sat, Aug 05, 2017 at 02:52:57AM +0900, Ian Y. Choi wrote:
Hello Sean,
For soft string freezes as a translator's view, trying the way you suggested for server projects would be good assuming that: - The volume of changes (e.g., the number of sentences, ratio of changes) needs to be properly limited
Completely agree. I'm more interested in changing the process around this than the policy. I would hope we would never get beyond the single digits in number of string changes during soft string freeze. If that happens, we are likely letting too many trivial things through than we should at this point.
- The string change needs to be well notified to translators (e.g., sharing to openstack-i18n mailing list)
I'm not sure how many folks are on the openstack-i18n mailing list. As the mail manager informed me shortly after sending my last reply, I am not so my copy to that list was rejected. It might be better to keep it on -dev. Although we are really trying to get the attention of the i18n team. Maybe we could make it a requirement that each project's PTL (or designated i18n liason) be subscribed to that mailing list in order to submit the notice of string changes allowed during soft freeze.
- It would be so nice if I18n team can keep track of original string changes in Zanata - translate.openstack.org but currently it is not easy unfortunately.
For hard string freezes, in my honest opinion, it is difficult to change the current policy because some translation sync support activities for a stable branch in openstack-infra [1] and addition of a stable version in translate.openstack.org [2] are dealt.
Totally agree. Hard freeze should be a hard freeze. Only if there is a last minute critical fix that absolutely must get through would be the only reason I would want to see string changes allowed. And that better be a very rare thing.
From those views, I would like to discuss more opinions and would we try better approach from the next development cycle with agreement for server projects?
With many thanks,
/Ian
[1] https://review.openstack.org/#/c/435812/1/jenkins/jobs/projects.yaml@1146 [2] https://translate.openstack.org/iteration/view/cinder/stable-ocata
participants (2)
-
Ian Y. Choi
-
Sean McGinnis