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

[Amye Scavarda]

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?
- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180314/157893ea/attachment.html>