[Gluster-Maintainers] Backport acceptance criteria

[Shyam]

On 05/07/2016 04:37 AM, Niels de Vos 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.

+1 overall

>
> 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

I would extend this somehow to state, change SHOULD NOT break 
client-server interaction. So that any minor/patch release keeps the 
client and server independently up-gradable, and does not make it so 
that their interaction will break.

>
> 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
> http://www.gluster.org/mailman/listinfo/maintainers
>