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

Amar Tumballi atumball at redhat.com
Tue Dec 12 11:45:21 UTC 2017 

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


   -

   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.

<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/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both

Regards,
Amar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20171212/dedd1cfa/attachment-0001.html>

More information about the maintainers mailing list