[Gluster-Maintainers] Maintainers meeting Agenda: Dec 13th
Atin Mukherjee
amukherj at redhat.com
Wed Dec 13 04:34:24 UTC 2017
On Tue, Dec 12, 2017 at 5:15 PM, Amar Tumballi <atumball at redhat.com> 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)
> <https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#bj-link0>BJ
> Link
>
> - Bridge: https://bluejeans.com/205933580
> - Download: <Add link>
>
>
> <https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#attendance0>
> Attendance
>
> - [Sorry Note] <Add your name if you can’t make it
> - <Add your name after joining the call>
>
>
> <https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#agenda0>
> 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]
>
>
> <https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#this-is-for-everyone-entering-from-github>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.
>
>
> <https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#any-bugzilla-triage>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
> <https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&classification=Community&keywords=FutureFeature%2C%20&keywords_type=allwords&list_id=8212428&product=GlusterFS&query_format=advanced>
>
>
> <https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#for-developers-for-patch-submission>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>
>
>
> <https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#round-table>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.
>
>
> <https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#decisions>
> Decisions
>
> - <Add any decisions taken in meeting here>
>
> ----
> The notes are taken here: https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvAT
> IiFhJgCYarBQCMCYIQA===?both
>
> Regards,
> Amar
>
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20171213/e85d0037/attachment-0001.html>
More information about the maintainers
mailing list