Hi Thierry, Thanks for a great summary.
I don't really share your view that there is a "us vs them" attitude emerging between operators and developers (but as someone with a foot in both camps maybe I'm just thinking that because otherwise I'd become even more bi-polar :-) I would suggest though that the criteria for core reviewers is maybe more slanted towards developers that operators, and that it would be worth considering if there is some way to recognised and incorporate the different perspective that operators can provide into the review process. Regards, Phil > -----Original Message----- > From: Thierry Carrez [mailto:thie...@openstack.org] > Sent: 02 January 2014 09:53 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova] minimum review period for functional > changes that break backwards compatibility > > 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 ? > > For the cases where we underestimate the impact of a change, there is no > magic bullet. So, like Sean said, we need to continue improving the number > of things we cover by automated testing. We also need to continue > encouraging a devops culture. When most developers are also people > running clouds, we are better at estimating operational impact. > > I've seen a bit of "us vs. them" between operators and developers recently, > and this is a dangerous trends. A sysadmin-friendly programming language > was picked for OpenStack for a reason: to make sure that operation-minded > developers and development-minded operators could all be part of the > same game. If we create two separate groups, tension will only get worse. > > -- > Thierry Carrez (ttx) > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
