Open Stack

On 12/28/2013 11:14 AM, Tim Bell wrote:
> I think there is a need for an incompatible change review process which includes more of the community than just those performing the code reviews. This kind of change can cause a lot of disruption for those of us running clouds so it is great to see that you are looking for more input.
>
> In the past, it has been proposed to also highlight incompatible changes to the openstack-operators list which is likely to reach those of us who will be most affected by the change. A similar process for API changes could also be applied to reach out for those who use OpenStack clouds. The change can then be reviewed as to how to minimise the impact (if significant) along with getting a larger group of people involved in understanding the merits of the change compared to the risks/effort for those running clouds in production.
+1
Posting proposed incompatible changes to the operators list would be 
good, along with a message once a change is committed. Perhaps this 
could even be done automatically via the DocImpact tag. It would also be 
good to create the icehouse release notes and update them in real time.

  -David


>
> Are there any other proposals for how to handle incompatible changes ?
>
> Tim
>
> From: Day, Phil [mailto:philip.day at hp.com]
> Sent: 28 December 2013 16:21
> To: OpenStack Development Mailing List (openstack-dev at lists.openstack.org)
> Subject: [openstack-dev] [nova] minimum review period for functional changes that break backwards compatibility
>
> Hi Folks,
>
> I know it may seem odd to be arguing for slowing down a part of the review process, but I'd like to float the idea that there should be a minimum review period for patches that change existing functionality in a way that isn't backwards compatible.
>
> The specific change that got me thinking about this is https://review.openstack.org/#/c/63209/ which changes the default fs type from ext3 to ext4.    I agree with the comments in the commit message that ext4 is a much better filesystem, and it probably does make sense to move to that as the new default at some point, however there are some old OS's that may still be in use that don't support ext4.  By making this change to the default without any significant notification period this change has the potential to brake existing images and snapshots.  It was already possible to use ext4 via existing configuration values, so there was no urgency to this change (and no urgency implied in the commit messages, which is neither a bug or blueprint).
>
> I'm not trying to pick out the folks involved in this change in particular, it just happened to serve as a good and convenient example of something that I think we need to be more aware of and think about having some specific policy around.  On the plus side the reviewers did say they would wait 24 hours to see if anyone objected, and the actual review went over 4 days - but I'd suggest that is still far too quick even in a non-holiday period for something which is low priority (the functionality could already be achieved via existing configuration options) and which is a change in default behaviour.  (In the period around a major holiday there probable needs to be an even longer wait).     I know there are those that don't want to see blueprints for every minor functional change to the system, but maybe this is a case where a blueprint being proposed and reviewed may have caught the impact of the change.    With a number of people now using a continual deployment approach any change in default behaviour needs to be considered not just  for the benefits it brings but what it might break.  The advantage we have as a community is that there are lot of different perspectives that can be brought to bear on the impact of functional changes, but we equally have to make sure there is sufficient time for those perspectives to emerge.
>
> Somehow it feels that we're getting the priorities on reviews wrong when a low priority changes like this which can  go through in a matter of days, when there are bug fixes such as https://review.openstack.org/#/c/57708/ which have been sitting for over a month with a number of +1's which don't seem to be making any progress.
>
> Cheers,
> Phil
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev