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]
- [WHY]
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
Once user answers all these questions, provide ‘SpecApproved’ flag.
- 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.
- 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-formatin./rfc.shitself - 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 :-)
- Suggestion is to use
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
asanbuilds) - yada! yada! <add if you need more>
- Make parallel / chunked tests a reality
- <Add more here>
- Have more category of tags (like KNOWNISSUE, BADTEST, etc)
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
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
