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) * 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 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
signature.asc
Description: PGP signature
_______________________________________________ maintainers mailing list maintainers@gluster.org http://www.gluster.org/mailman/listinfo/maintainers