[Gluster-Maintainers] More on 'SpecApproved' and 'DocApproved'.

Amar Tumballi atumball at redhat.com
Fri Apr 20 11:13:00 UTC 2018


>
> - github flag enforcement for all features (doc and spec requirement)
> [amar]
>

I tried to add these details to 'glusterdocs' repo [1], but noticed that we
don't talk much about github is used for 'RFE' itself there. So, to unblock
developers for the branching of 4.1 by information planning to write the
email with details. will fix the other docs soon(ish)- Any help here would
be appreciated with *Gluster Swags*.

The intention behind making these flags mandatory is explained in my
earlier email [2]. As the same is now enforced, more details below.

If any one of the 'DocApproved', 'SpecApproved' label is missing, the
'smoke' test name  'comment-on-issue' [3] would keep failing, if your
commit message as a reference to github issues.

*What is 'DocApproved' and how to get this?*

Doc Approved means, the data required for 'user' to use the feature (all
the options, CLI commands, how to setup etc) are provided, and also brief
note of what the feature is about, is written down, so the release lead can
just pick this information, and use it in release process. (Note, the idea
is to automate this too, so release-lead's role is to control the
cherry-picking after the branch-out).

We would consider a blog with all these points also can be considered for
this.

*What is 'SpecApproved' and how to get this label?*

Spec (or Specification) deals with the design of the feature, (mostly
similar to gluster-spec repo we have). Answer the question of who needs it
and why? (Detail on the usecase). How (for developers) part of the design
explained.


*Who / How to set this label ?*

Today, anyone who is member of glusterfs project, and has access to
set/unset labels can do it. But the advise is to leave it to general
architects listed in the MAINTAINERS file, mainly as there may be few more
questions pending on the spec. Also, as a top level guideline to the
architects, please write a summary of why you are giving this label, what
are the things you considered etc, without which there may be some conflict
of interests here.

Initial few days/weeks, I along with Shyam would closely monitor this label
business. Every one is free to ask more question to developers if design is
not clear.

In future, like many other projects, we want to automate it, where the
label is give after certain 'comment commands' are given (like 3 people
giving 'i approve' type of message in issue would automatically get it the
label).

*What if I have more questions? or improvement suggestion?*
Please ask, file a bug, write email.. there are many options. Improvements
come only when people suggest / provide feedback etc.

Regards,
Amar

[1] - https://github.com/gluster/glusterdocs
[2] -
http://lists.gluster.org/pipermail/gluster-devel/2018-April/054696.html
[3] - https://build.gluster.org/job/comment-on-issue/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20180420/f3a8736c/attachment.html>


More information about the maintainers mailing list