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 <rgowd...@redhat.com> wrote: > > > On Wed, Mar 14, 2018 at 8:27 PM, Amye Scavarda <a...@redhat.com> wrote: > >> Responding on the architects question: >> >> On Tue, Mar 13, 2018 at 9:57 PM, Pranith Kumar Karampuri < >> pkara...@redhat.com> wrote: >> >>> >>> >>> On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri < >>> pkara...@redhat.com> wrote: >>> >>>> >>>> >>>> On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi <atumb...@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 <j...@pl.atyp.us> >> M: Vijay Bellur <vbel...@redhat.com> >> P: Amar Tumballi <ama...@redhat.com> >> P: Pranith Karampuri <pkara...@redhat.com> >> P: Raghavendra Gowdappa <rgowd...@redhat.com> >> P: Shyamsundar Ranganathan <srang...@redhat.com> >> P: Niels de Vos <nde...@redhat.com> >> P: Xavier Hernandez <xhernan...@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@gluster.org >>> http://lists.gluster.org/mailman/listinfo/gluster-devel >>> >> >> >> >> -- >> Amye Scavarda | a...@redhat.com | Gluster Community Lead >> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> > > -- Amye Scavarda | a...@redhat.com | Gluster Community Lead
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel