[Gluster-Maintainers] Backport acceptance criteria
kshlmster at gmail.com
Wed Jun 15 14:57:43 UTC 2016
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 , 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
>> 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 . I've begun with the existing
release process doc from glusterdocs.
Doesn't yet contain all the criteria.
More information about the maintainers