Open Stack

On Thu, Jan 2, 2014 at 8:23 PM, Thierry Carrez <thierry at openstack.org>wrote:

> Tim Bell wrote:
> >> - 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 ?
> >
> > 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.
>
> IMHO there are a few takeaways from this thread...
>
> When a proposed patch is known to change default behavior, or break
> backward compatibility, or cause an upgrade headache, we should
> definitely be more careful before finally approving the change. We
> should also have a mechanism to engage with users and operators so that
> they can weigh in. In the worst case scenario where there is no good
> solution, at least they are informed that the pain is coming. One
> remaining question would be... what is that mechanism ? Mail to the
> general list ? the operators list ? (should those really be two separate
> lists ?) Some impact tag that upgrade-minded operators can subscribe to ?
>

Whilst I don't think that having a minimum review period would have helped
in this case because of
the volume of patches being submitted, I think where there are backwards
incompatible changes that aren't urgent,
a post to the appropriate mailing lists should be done. And referenced in
the commit message which would
help with the reviews as well.

We could have a reasonable minimum period for people to respond to a
mailing list post
which would not necessarily affect the how fast the patch actually gets
merged because
the message can be sent in advance of someone actually working on a patch.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140103/d12789ba/attachment.html>