[Gluster-Maintainers] Backport acceptance criteria

[Niels de Vos]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160507/5fc236ac/attachment.sig>