[Gluster-devel] [Gluster-Maintainers] Release 4.1: LTM release targeted for end of May

[Pranith Kumar Karampuri]

On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri <
pkarampu at redhat.com> wrote:

>
>
> On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi <atumball at redhat.com>
> wrote:
>
>> >>
>>> >> Further, as we hit end of March, we would make it mandatory for
>>> features
>>> >> to have required spec and doc labels, before the code is merged, so
>>> >> factor in efforts for the same if not already done.
>>> >
>>> >
>>> > Could you explain the point above further? Is it just the label or the
>>> > spec/doc
>>> > that we need merged before the patch is merged?
>>> >
>>>
>>> I'll hazard a guess that the intent of the label is to indicate
>>> availability of the doc. "Completeness" of code is being defined as
>>> including specifications and documentation.
>>>
>>>
>> I believe this has originated from maintainers meeting agreements [1] .
>> The proposal to make a spec and documentation mandatory was submitted 3
>> months back and is documented, and submitted for comment @
>> https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI
>> yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing
>>
>>
> Thanks! This clears almost all the doubts I had :).
>

The document above refers to Architects - "Now Architects are approved to
revert a patch which violates by either not having github issue nor bug-id,
or uses a bug-id to get the feature in etc."

Who are they? What are their responsibilities?


>
>
>> The idea is, if the code is going to be released, it should have relevant
>> documentation for users to use it, otherwise, it doesn't matter if the
>> feature is present or not. If the feature is 'default', and there is no
>> documentation required, just mention it, so the flags can be given. Also,
>> if there is no general agreement about the design, it doesn't make sense to
>> merge a feature and then someone has to redo things.
>>
>> For any experimental code, which we want to publish for other developers
>> to test, who doesn't need documentation, we have 'experimental' branch,
>> which should be used for validation.
>>
>
>>  [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece
>> mber/054070.html
>>
>
>
>
> --
> Pranith
>



-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180314/a994d259/attachment.html>