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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
