[Gluster-devel] 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)
<https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#bj-link>BJ
Link
- Bridge: https://bluejeans.com/205933580
- Download: https://bluejeans.com/s/jnltM/
<https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#attendance>
Attendance
- [Sorry Note] amye, Atin (conflicting meeting)
- Shyam, Amar, Nigel, Ravi, Jeff, Soumya, kaleb, Xavi, kaushal, Rafi,
<Add your name here>
<https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#agenda>
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
<http://lists.gluster.org/pipermail/gluster-devel/2017-November/053995.html>
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
<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]
<https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#decisions>
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20171129/1f6f45ee/attachment-0001.html>
More information about the Gluster-devel
mailing list