<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Yury,<div><br></div><div>Please, see my comments inline.</div><div><div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"></div></div></div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 19, 2019 at 9:32 AM Kulazhenkov, Yury <<a href="mailto:Yury.Kulazhenkov@dell.com">Yury.Kulazhenkov@dell.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>I'm currently maintain VxFlex OS(ScaleIO) cinder driver. Driver require some changes to support future VxFlex OS release.<br>We want to add this changes to Stein release and if it possible backport them to old supported releases.<br>I have couple questions:<br>  1. Is it still possible to submit patches which extend driver functionality in Stein release cycle?<br>          If such changes are still possible, then I have another question:<br>          I already submitted patch that renames ScaleIO driver to VxFlex OS (<a href="https://review.openstack.org/#/c/634397/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/634397/</a>).<br>          Is it possible that this patch will be merged during Stein release cycle? <br>          In other words, I'm interesting, should I prepare "new feature" patch based on this "renaming" patch (as patch chain)<br>          or it will be better to prepare separate patch based on master branch state?<br></blockquote><div>We're about two weeks before Stien-3 milestone [1]. It's a feature freeze milestone, so it means all features should be merged before it. If you miss this deadline, these patches will be merged in Train.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2. Is it possible to add new driver features (changes for compatibility, to be more accurate) for currently supported Openstack releases?<br>    Any rules, policy or special workflow for that?Cinder code with drivers should stable policy [1]<br></blockquote><div><br></div><div><div>Cinder code with drivers should stable policy [2], so we can't backport any driver features to stable branches.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks,<br>
<br>Yury<br>
<br></blockquote><div><br></div><div><br></div><div><div>[1] <a href="https://releases.openstack.org/stein/schedule.html">https://releases.openstack.org/stein/schedule.html</a></div><div>[2] <a href="https://docs.openstack.org/project-team-guide/stable-branches.html">https://docs.openstack.org/project-team-guide/stable-branches.html</a></div></div><div><br></div><div>Regards,<br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr">Ivan Kolodyazhny,<br></div></div></div><div><a href="http://blog.e0ne.info/" target="_blank">http://blog.e0ne.info/</a> </div></div></div>