[Gluster-Maintainers] Backport acceptance criteria

[Niels de Vos]

On Wed, Jun 08, 2016 at 07:12:12PM +0530, Kaushal M wrote:
> 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).

Great, that is REALLY much appreciated!

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

Yes, of course.

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

Indeed! Some status checking scripts parse the output of the CLI (in
XML-format or not) and we should prevent breaking those.

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

This was mainly written with the stable/bugfix releases in mind, and not
so much for new major versions. Even for new versions I would be
hesitant to backport anything that does not match the criteria from the
1st email. Any major changes suggest that the feature was not ready at
the time of branching, and it may be a better decision to move it to the
next version instead (or at least have it marked as experimental).

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

Thanks! Please put it in an etherpad and share the link. We can then all
work together on it. ALL maintainers are expected to asssist, or at
minimal acknowledge the criteria.

Niels
-------------- 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/20160610/675b4589/attachment.sig>