[Gluster-Maintainers] Backport acceptance criteria

[Niels de Vos]

On Wed, Jun 15, 2016 at 09:20:46PM +0530, Pranith Kumar Karampuri 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.
> >
> > 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?

I'm pretty sure there we can accomodate exceptions for some of these
rules. But, they really need to be exceptions. I already expect that
each patch has a test-case, and if that is not possible, it should be
mentioned in the commit message. (And also there are exceptions for
that, like general cleanup, spelling fixes etc.)

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

Great! I hope we can move this forward fast.

Thanks for reviewing,
Niels

> 
> 
> >
> > 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 --------------
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/20160615/06958d16/attachment.sig>