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....@hp.com]
Sent: 28 December 2013 16:21
To: OpenStack Development Mailing List (openstack-dev@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 chan
ge 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@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
