On Wed, Mar 14, 2018 at 10:27 AM, 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? > I had heard reference to this role in a Maintainer's meeting too. It was in the context of People meeting up during FAST18 and discussing about the future of Glusterfs. Clarifications on this role is much appreciated. Specifically, * Was there a process to decide on who are they? * If yes, when did this happen? > >> >> >>> 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 >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel