Re: [Gluster-Maintainers] Maintainers meeting Agenda: Dec 13th

Atin Mukherjee <amukherj@xxxxxxxxxx> · Wed, 13 Dec 2017 10:04:24 +0530

On Tue, Dec 12, 2017 at 5:15 PM, Amar Tumballi <atumball@xxxxxxxxxx> wrote:
This is going to be a longer meeting if we want to discuss everything here, so please consider going through this before and add your points (with name) in the meeting notes. See you all tomorrow.

Meeting date: 12/13/2017 (Dec 13th, 19:30IST, 14:00UTC, 09:00EST)
BJ Link
Bridge: https://bluejeans.com/205933580
Download: <Add link>
Attendance
[Sorry Note] <Add your name if you can’t make it
<Add your name after joining the call>
Agenda
Any AI from previous meeting?
Process Automation proposal
[WHY]We should have processes to help fast track the project’s progress
Any new contributor should find the steps non-confusing
If it is not enforced in the process, no guidelines would be enforced in practise
If any developer is ‘spending extra time’ to follow the process, it is not a good sign for the project
[HOW]
This is for everyone entering from github:
For bugs
There is one liner in github issues by default (at the top) saying your bugs goto bugzilla.[One time activity] Change the current github issues default msging to just give one line suggestion, instead of every detail.
If they still go ahead and create it, anyone triaging the issues marks it as ‘Type:Bug’[Manual] This human intervention expected in any ‘automation’. We can do it as part of bug triage too.
Upon adding ‘Type:Bug’ tag, a bug is automatically created in bugzilla. Issue gets closed with URL to bugzilla ID, asking creator to refer bugzilla for further updates.[Automatic] Needs jenkins job (or other github automations)
For questions
There is one liner in github issues by default (at the top - 1) saying your questions go into mailing list.[One time activity] Change the current github issues default msging to just give one line suggestion, about mailing list.
If they still go ahead and create it, anyone triaging the issues marks it as ‘Question’[Manual] This human intervention expected in any ‘automation’. We can do it as part of bug triage too.
Upon adding ‘Question’ tag, the question gets posted to mailing list, with creator in Cc, the archive URL gets posted to github, and the issue gets closed.[Automatic] Needs jenkins job (or other github automations)
For features
Clearly ask the questions (ie, these are part of gluster specs)
  Ask about monitoring 
  Ask about events
  Ask about test cases
  Ask about supporting / debugging
  Ask about path from alpha to beta to GA for the feature.
  Ask for contact person
  Ask about release-notes
  Usecase / impact areas

I expect the design doc to be also part of this checklist and a patch can only be  'SpecApproved" if its corresponding design doc is already approved and merged. There might be some features where all of the above may not be applicable. So is it the maintainer's or the owner's responsibility to tick the respective check box or mark them as N/A ?
Once user answers all these questions, provide ‘SpecApproved’ flag.

So this flag will be visible in the gerrit UI only when a patch has a respective github issue id and the submit button will stay as disabled till this flag is +1ed?

Only maintainers are allowed to provide this flag.
Ask developer to provide documentation. (Can be part of initial spec, if not can be followup question automatically posted after ‘specApproved’ flag).
If provided give ‘DocApproved’ flag.

As I mentioned earlier, I'd think that we don't need this flag as it can be part of the overall spec-list check.

Again, only maintainers are allowed to provide this flag.
For every patch in glusterfs project, (as part of smoke), run a test to see if a patch is for the feature, if yes (ie, a github issue is present), check if ‘SpecApproved’ and ‘DocApproved’ is present, and only then a feature gets +1 vote.
Expectation is every patch posted is either a bug fix or a feature.
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.
It is fine to revert a patch where SpecApproved and DocApproved is given by the author of the patch, and doesn’t meet the guidelines.
If the same person’s patches gets reverted more than 3 times for violations, his github label setting access can be revoked. No issues with ‘maintainership’ of glusterfs project as such.
Any Bugzilla Triage
If a bug gets Keyword ‘FutureFeature’ during Triaging (Manual) then the automation creates a github issue automatically, and posts the issue URL in bugzilla and closes as NOTABUG.[Automatic] Need a script to run every day to query and close such bugs and create github issues.
Current list of RFEs in community bugzilla
For developers for patch submission
Coding Standards:
Suggestion is to use clang-format in ./rfc.sh itself
This is make user not bother about coding standards, and can use their favorite editor and settings.
Run clang again on the patch to have validations against people directly submitting the patch.
This will make sure we as reviewers don’t need to use our braincycles to validate coding standards in the patch.
As an extention, consider running spell check tool too, to make sure log messages are not having spelling errors :-)
Testing:
Have more category of tags (like KNOWNISSUE, BADTEST, etc)Motive is for having set of tests mark as ‘known TIMING issues’
Tag for saying needs IPv6
Tag for saying needs XFS/LVM etc
Tag for saying this test is not needed to run for every patch, but should run in nightly regressions. eg, tests which takes lot of time.
Tag for saying have known memory leak (ie, this test fails with asan builds)
yada! yada! <add if you need more>
Make parallel / chunked tests a reality
<Add more here>
Round Table
[Amar] Do we need a STM release in future? ie, after above process is done.STM’s main goal is to say the release is not good to be supported, we are using this release to add feature, and will stabilize it by next LTM.
With introduction of ‘experimental’ branch, and a proper streamline of process where documentation and tests are also landed with feature, it may be fine to say feature is ready.
Also say only if line-coverage is above certain limit, then only it will figure out in release-notes.
Decisions
<Add any decisions taken in meeting here>
----
The notes are taken here: https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both

Regards,
Amar

_______________________________________________

maintainers mailing list

maintainers@xxxxxxxxxxx

http://lists.gluster.org/mailman/listinfo/maintainers

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel