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

[Amye Scavarda]

We could stand to use our words better on this stuff. Even though we've
thought about it a lot, it's not always clear about what we mean in the
roles and responsibilities.
I'll put a ticket into the Community Working Group to use more words about
this.
- amye

On Wed, Mar 14, 2018 at 8:29 AM, Raghavendra Gowdappa <rgowdapp at redhat.com>
wrote:

>
>
> 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?
>> - amye
>>
>
> Thanks for that clarification amye. I had a confusion whether the
> terminology was referring to roles listed in MAINTAINERS file. Now that
> you've clarified, my confusion is cleared.
>
>
>>
>>>
>>>
>>>>
>>>>
>>>>> 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
>>
>> _______________________________________________
>> 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/f0fec819/attachment.html>