Maintainers meeting minutes - Nov 29th 2017.

[Amar Tumballi <atumball@xxxxxxxxxx>]

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

BJ Link

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

Attendance

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

Agenda

• 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 from Shyam:

  • 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 features.
      • 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 4.0.
      • 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 contributor.
    • [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 contribute.
    • [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 forward.
    • 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 well?

• [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 too?
    • 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, 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]

Decisions

• 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)

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