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