[Gluster-Maintainers] Backport acceptance criteria
Pranith Kumar Karampuri
pkarampu at redhat.com
Wed Jun 15 15:50:46 UTC 2016
On Sat, May 7, 2016 at 2:07 PM, Niels de Vos <ndevos at redhat.com> wrote:
> 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
> Based a little on RFC 2119 , 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.
> 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?
> * 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.
> 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 at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the maintainers