[Gluster-Maintainers] Backport acceptance criteria

[Kaushal M]

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

This is really, really late, but this is good list for backport criteria.
I agree with almost all the criteria, and have commented inline on
which I don't (yet).

> 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

This should be allowed only if the new values don't break old clients/servers.
If it does, the change would require a public discussion and agreement
from maintainers to be accepted, and the breakage should be noted
clearly in the release notes and documentation.

>
>  * it is NOT RECOMMENDED to modify the contents of existing log
>    messages, automation and log parsers can depend on the phrasing

I would also add a criteria for CLI output as well. We cannot have CLI
outputs changing too much on minor releases.

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


I'd like it if this criteria became stricter as release deadline
approached. This will help things move faster earlier in the release
cycle.
For example, during the initial part of a release cycle large patches
can get in if the maintainer of the component is okay.
Towards the end, (say 1 week away from an RC), such changes will need
to get agreement from a majority of the maintainers to be merged.
After an RC is done, such changes will not be merged at all.

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

I'd like a similar set of criteria for the merge window for a release
following the proposed release timelines.
I think I'll start writing a proper document for the proposal, using
the language from rfc2119. It should help drive better discussions
around it.

>
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
>