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

[Pranith Kumar Karampuri]

On Wed, Mar 14, 2018 at 8:27 PM, Amye Scavarda <amye at redhat.com> wrote:

> Responding on the architects question:
>
> On Tue, Mar 13, 2018 at 9:57 PM, 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?
>>
>
> In our last reboot of the maintainers readme file, we expanded the
> architects role:
> https://github.com/gluster/glusterfs/blob/master/MAINTAINERS
> General Project Architects
> --------------------------
> M: Jeff Darcy <jeff at pl.atyp.us>
> M: Vijay Bellur <vbellur at redhat.com>
> P: Amar Tumballi <amarts at redhat.com>
> P: Pranith Karampuri <pkarampu at redhat.com>
> P: Raghavendra Gowdappa <rgowdapp at redhat.com>
> P: Shyamsundar Ranganathan <srangana at redhat.com>
> P: Niels de Vos <ndevos at redhat.com>
> P: Xavier Hernandez <xhernandez at datalab.es>
> What should we work to make more clear about this?
>

Wow, embarrassing, I am an architect who doesn't know his responsibilities.
Could you let me know where I could find them?


> - amye
>
>
>>
>>
>>>
>>>
>>>> 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
>>
>
>
>
> --
> Amye Scavarda | amye at redhat.com | Gluster Community Lead
>



-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180316/9d2c614a/attachment-0001.html>