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 > > >> >> >>> 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