<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 2, 2014 at 8:23 PM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Tim Bell wrote:<br>
>> - Changes in default behaviour:   Always likely to affect existing systems in some way.   Maybe we should have an additional type of review vote that comes from people who are recognised as reperensting large production deployments ?<br>

><br>
> This is my biggest worry...  there are changes which may be technically valid but have a significant disruptive impact on those people who are running clouds. Asking the people who are running production OpenStack clouds to review every patch to understand the risks and assess the migration impact is asking a lot.<br>

<br>
</div>IMHO there are a few takeaways from this thread...<br>
<br>
When a proposed patch is known to change default behavior, or break<br>
backward compatibility, or cause an upgrade headache, we should<br>
definitely be more careful before finally approving the change. We<br>
should also have a mechanism to engage with users and operators so that<br>
they can weigh in. In the worst case scenario where there is no good<br>
solution, at least they are informed that the pain is coming. One<br>
remaining question would be... what is that mechanism ? Mail to the<br>
general list ? the operators list ? (should those really be two separate<br>
lists ?) Some impact tag that upgrade-minded operators can subscribe to ?<br></blockquote><div><br></div><div>Whilst I don't think that having a minimum review period would have helped in this case because of<br>the volume of patches being submitted, I think where there are backwards incompatible changes that aren't urgent,<br>
a post to the appropriate mailing lists should be done. And referenced in the commit message which would<br>help with the reviews as well. <br><br>We could have a reasonable minimum period for people to respond to a mailing list post<br>
which would not necessarily affect the how fast the patch actually gets merged because<br>the message can be sent in advance of someone actually working on a patch.<br></div><div><br></div><div>Chris<br></div></div></div>
</div>