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

[Raghavendra Gowdappa]

On Wed, Mar 14, 2018 at 10:27 AM, Pranith Kumar Karampuri <
pkarampu at redhat.com> wrote:

>
>
> 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?
>

I had heard reference to this role in a Maintainer's meeting too. It was in
the context of People meeting up during FAST18 and discussing about the
future of Glusterfs. Clarifications on this role is much appreciated.
Specifically,

* Was there a process to decide on who are they?
* If yes, when did this happen?


>
>>
>>
>>> 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
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180314/db360afe/attachment-0001.html>