On Wed, Jun 15, 2016 at 09:20:46PM +0530, Pranith Kumar Karampuri wrote: > On Sat, May 7, 2016 at 2:07 PM, Niels de Vos <nde...@redhat.com> wrote: > > > Hi, > > > > with the close to getting released 3.8, I would like to make sure that > > we do not start to backport features and make invasive changes. This > > should ensure us that most developers work on the next version with a > > broader feature set, and spend less time on backporting and testing > > those backported changes. We should make sure to address bugs in the > > stable 3.8 release, but keep away from user (or automation) visible > > changes. > > > > Based a little on RFC 2119 [1], I'm proposing several categories that > > describe if a backport to a stable branch is acceptable or not. These > > "backport acceptance criteria" should be added to our documentation > > after a brief discussion among the maintainers of the project. > > > > I'd like to encourage all maintainers to review and comment on my > > current proposed criteria. It is my expectation that others add more > > items to the list. > > > > Maintainers that do not share their opinion, are assumed to be in > > agreement. I plan to have this list ready for sharing on the devel list > > before the next community meeting on Wednesday. > > > > Thanks, > > Niels > > > > > > Patches for a stable branch have the following requirements: > > > > * a change MUST fix a bug that users have reported or are very likely > > to hit > > > > * each change SHOULD have a public test-case (.t or DiSTAF) > > > > It is extremely difficult to come up with an automated testcase for fixing > a race. What is the best way forward in that situation?
I'm pretty sure there we can accomodate exceptions for some of these rules. But, they really need to be exceptions. I already expect that each patch has a test-case, and if that is not possible, it should be mentioned in the commit message. (And also there are exceptions for that, like general cleanup, spelling fixes etc.) > > * a change MUST NOT add a new FOP > > > > * a change MUST NOT add a new xlator > > > > * a change SHOULD NOT add a new volume option, unless a public > > discussion was kept and several maintainers agree that this is the > > only right approach > > > > * a change MAY add new values for existing volume options, these need > > to be documented in the release notes and be marked as a 'minor > > feature enhancement' or similar > > > > * it is NOT RECOMMENDED to modify the contents of existing log > > messages, automation and log parsers can depend on the phrasing > > > > * a change SHOULD NOT have more than approx. 100 lines changed, > > additional public discussion and agreement among maintainers is > > required to get big changes approved > > > > > * a change MUST NOT modify existing structures or parameters that get > > sent over the network > > > > * existing structures or parameters MAY get extended with additional > > values (i.e. new flags in a bitmap/mask) if the extensions are > > optional and do not affect older/newer client/server combinations > > > > Rest of the guidelines seem good. Great! I hope we can move this forward fast. Thanks for reviewing, Niels > > > > > > NOTE: Changes to experimental features (as announced on the roadmap and > > in the release notes) are exempted from these criteria, except for > > the MOST NOT requirements. These features explicitly may change > > their behaviour, configuration and management interface while > > experimenting to find the optimal solution. > > > > 1. https://tools.ietf.org/html/rfc2119 > > > > _______________________________________________ > > maintainers mailing list > > maintainers@gluster.org > > http://www.gluster.org/mailman/listinfo/maintainers > > > > > > > -- > Pranith
signature.asc
Description: PGP signature
_______________________________________________ maintainers mailing list maintainers@gluster.org http://www.gluster.org/mailman/listinfo/maintainers