[Gluster-Maintainers] Backport acceptance criteria

[Kaushal M]

On Fri, Jun 10, 2016 at 6:39 AM, Niels de Vos <ndevos at redhat.com> wrote:
> 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.

I've started the document here [1]. I've begun with the existing
release process doc from glusterdocs.
Doesn't yet contain all the criteria.

[1]: https://public.pad.fsfe.org/p/glusterfs-release-process-201606

>
> Niels