<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 7, 2016 at 2:07 PM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
with the close to getting released 3.8, I would like to make sure that<br>
we do not start to backport features and make invasive changes. This<br>
should ensure us that most developers work on the next version with a<br>
broader feature set, and spend less time on backporting and testing<br>
those backported changes. We should make sure to address bugs in the<br>
stable 3.8 release, but keep away from user (or automation) visible<br>
changes.<br>
<br>
Based a little on RFC 2119 [1], I'm proposing several categories that<br>
describe if a backport to a stable branch is acceptable or not. These<br>
"backport acceptance criteria" should be added to our documentation<br>
after a brief discussion among the maintainers of the project.<br>
<br>
I'd like to encourage all maintainers to review and comment on my<br>
current proposed criteria. It is my expectation that others add more<br>
items to the list.<br>
<br>
Maintainers that do not share their opinion, are assumed to be in<br>
agreement. I plan to have this list ready for sharing on the devel list<br>
before the next community meeting on Wednesday.<br>
<br>
Thanks,<br>
Niels<br>
<br>
<br>
Patches for a stable branch have the following requirements:<br>
<br>
* a change MUST fix a bug that users have reported or are very likely<br>
to hit<br>
<br>
* each change SHOULD have a public test-case (.t or DiSTAF)<br></blockquote><div><br></div><div>It is extremely difficult to come up with an automated testcase for fixing a race. What is the best way forward in that situation?<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* a change MUST NOT add a new FOP<br>
<br>
* a change MUST NOT add a new xlator<br>
<br>
* a change SHOULD NOT add a new volume option, unless a public<br>
discussion was kept and several maintainers agree that this is the<br>
only right approach<br>
<br>
* a change MAY add new values for existing volume options, these need<br>
to be documented in the release notes and be marked as a 'minor<br>
feature enhancement' or similar<br>
<br>
* it is NOT RECOMMENDED to modify the contents of existing log<br>
messages, automation and log parsers can depend on the phrasing<br>
<br>
* a change SHOULD NOT have more than approx. 100 lines changed,<br>
additional public discussion and agreement among maintainers is<br>
required to get big changes approved<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* a change MUST NOT modify existing structures or parameters that get<br>
sent over the network<br>
<br>
* existing structures or parameters MAY get extended with additional<br>
values (i.e. new flags in a bitmap/mask) if the extensions are<br>
optional and do not affect older/newer client/server combinations<br></blockquote><div><br></div><div>Rest of the guidelines seem good.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
NOTE: Changes to experimental features (as announced on the roadmap and<br>
in the release notes) are exempted from these criteria, except for<br>
the MOST NOT requirements. These features explicitly may change<br>
their behaviour, configuration and management interface while<br>
experimenting to find the optimal solution.<br>
<br>
1. <a href="https://tools.ietf.org/html/rfc2119" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc2119</a><br>
<br>_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org">maintainers@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/maintainers</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div></div>