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? > 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@gluster.org >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> > > > > -- > Amye Scavarda | a...@redhat.com | Gluster Community Lead > -- Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel