[Gluster-Maintainers] Backport acceptance criteria

[Pranith Kumar Karampuri]

On Sat, May 7, 2016 at 2:07 PM, Niels de Vos <ndevos at 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?



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


-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160615/b67f76cb/attachment-0001.html>