[Gluster-Maintainers] Maintainers meeting minutes - Nov 29th 2017.

Amar Tumballi atumball at redhat.com
Wed Nov 29 15:49:18 UTC 2017

Meeting date: 11/29/2017 (Nov 29th, 19:30IST, 14:00UTC, 09:00EST)

   - Bridge: https://bluejeans.com/205933580
   - Download: https://bluejeans.com/s/jnltM/


   - [Sorry Note] amye, Atin (conflicting meeting)
   - Shyam, Amar, Nigel, Ravi, Jeff, Soumya, kaleb, Xavi, kaushal, Rafi,
   <Add your name here>



   Action Items from last meeting (if any)?:
   - Periodic regression tests are now nightly on master
      - Non-master branches are currently paused waiting for a pipeline
      job. Work in Progress. Needs testing and review.

   4.0 email
   - Is your feature/issue updated with proper milestone?
      - What is your preferred date for branch out?
         - Dec 15th?
         - Jan 15th?
            - Ravi: Jan is better. Still discussing implementation for some
            - Shyam: Mid-Dec is going to be a stretch. Mid-Jan works better.
            - Amar: Protocol, etc are changes which may need more time to
            get right.
            - Soumya: Jan 15 preferred.
            - Kaushal: mid-Jan looks better. Lot of work left to do.
            Separate discussion about landing GD2 work into glusterfs
repo so we can
            integrate and test faster.
            - Jeff: Given volume of patches involved in landing FB patches,
            Jan looks better.
            - Rafi: Snapshot work needs to be completed. Jan 15 is better.
            - Nigel: GD2 needs Centos7. We’re in the process of migration
            to El7. But as soon as we want to test with Centos7, we
have to re-do a lot
            of work to bring up new machines. GD2 has to land for this to work.
         - 4.1 LTM vs STM?
            - Amar: Taking the call right now is too early. Without
            migration plan we cannot call it “done”. Better to take a
call a month from
            - Shyam: Agreed.
         - Quality/Testing focus?
            - Reducing Coverity trend
            - Increasing line coverage trends.
            - If we add that as gate, release doesn’t go out until those
            targets are met.
            - It’s complicated. It’s not good enough to push out something
            we haven’t tested to our users.
            - Get more features in as experimental and stabilize over time.
            - We’ll meet Coverity goal in 4.0 because of work done in the
            last few months. Can only be done pre-branching
            - Coverage reports can be worked on post-branching.
            - If you remove a bunch of lines, increases coverage, because
            of how the math is done. We’ll never hit 100% because
we’ll have code for a
            lot of negative test cases.
            - Target specific components rather than entire project.
            Specific people can work on targetted components, while
getting a breather
            for feature-related work in a specific cycle.

   Getting more contribution from outside (non-RH/non-FB):
   - Are we right in expecting people to follow our guidelines?
      - As a maintainer what would you do if someone posts a PR in github,
      and is not willing to follow the gerrit workflow?
         - [Amar] I prefer to treat it same as how we agreed to proceed
         with continuing to rebase and send with --author intact to the
         - [Amar] At the moment, we should be more willing to accept any
         type of contribution, and respect author decision on how much
they want to
         - [Amar] Pointing them the gerrit workflow and asking to use our
         dev workflow is the right first step, but within a week if
nothing happens,
         maintainers / peers taking the patch up and sending it on --authors
         behalf is ideal.
         - [Nigel] What if we said we’ll take someone’s Github patch and
         shepherd it through the process for the first step. For more long-term
         contributors, we should ask them to use Gerrit.
         - [Ravi] We shouldn’t be flexible. For example, Kernel project.
         - [Amar] We shouldn’t be using Kernel as an example. We may miss
         drive-by contributors. It doesn’t help us grow, especially as
a project
         that doesn’t have a lot of external contributions.
         - [Shyam] We did a lot of work for the FB patches. The number of
         patches we moved from the FB branch to master is quite low. Even when
         patches come to Gerrit, we’re not enabling them.
         - The thought process is coming from someone who’s sent a patch,
         the person has not responded, and we want to fix issues with
it and move it
         - Snapshot patches on github (for btrfs), we moved it to Gerrit.
         But there were discussions and issues. Rafi worked it.

   [Nigel] Chunked Regressions have exposed new problems
   - Some of our tests do not work on Centos7.
      - Timing issues in tests show up when we run them on the cage VM
      - Job: https://build.gluster.org//job/chunked-regression/
      - Jeff: Workflow changes completely. FB has tests marked has flakey
      where they’re re-tried 5x.
      - Run them for 7 days and get data. Run them 5x is a good idea as

   [Nigel?] Can we enforce that only maintainers and peers can +2 patches?
   (Everyone else can +1)
   - The intention is to elevate people to maintainers sooner
      - Can other maintainers from different component merge the patches
         - Yes, subject to social convention.
            - Patch complexity and time counts as well.
         - What is ideal time of wait?

   GD2: <Didn’t discuss as there was no time>
   - Topics on how to get it to main repo
      - Is the current milestone
      <https://github.com/gluster/glusterd2/milestones>, fine for everyone?
      - [Nigel] some work on infra is required to get the regression.

   Round Table?
   - gluster-spec like template for github feature requests [Shyam]


   - Jan 15th Branch out for 4.0
   - Maintainers should keep an eye on patches which are important for
   module, but the authors are not very active.

Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20171129/1f6f45ee/attachment.html>

More information about the maintainers mailing list