[Gluster-Maintainers] Meeting minutes: 09/20/2017 (Sept 20th)
atumball at redhat.com
Wed Sep 20 18:16:14 UTC 2017
Meeting date: 09/20/2017 (Sept 20th)
- Bridge: https://bluejeans.com/205933580
- Download/Watch : https://bluejeans.com/s/mgtCo
- [Sorry Note] mscherer, kshlm, atinm, amye
- Amar, Rafi, Nigel, Milind, Nithya, Kaleb, Shyam, Xavi, Ravi, raghug,
AI from previous week
- [Nigel] Changes to ‘Submit Type’ - DONE on 2017-09-20 02:20 UTC
- [Amye] Email sent out with hotel information around Gluster Summit,
if you didn’t get it, ping me or ask around. – amye
Note: Archive old meeting notes to wiki so the hackmd is lighter.
- [Amar] Can we archive it in our website somewhere, so we know where to
search for old meeting minutes?
What are we doing with regression failure emails?
- You should all be getting emails from failures onto maintainers@
- [Atin] brick mux regression was on centos. volume status clients
command is broken. Root cause availble. We have reverted the new test
introduced in volume-status.t. regression is back to normal.
- [Atin] netbsd regression multiple test failures. Please look into
it if it falls into your components.
- tests/bitrot/bug-1373520.t (generated core)
- Let’s have a rotating group of people who look at failures.
- [shyam] Do they look at only releases or master? Preferably only
release branches, because master is overwhelming.
- [nigel] We should probably have one person look at all the
branches and especially master. A lot of our test runs are triggered
periodically against master. This person’s job would be chase down the
failures, find the right component, and get the fix pushed as soon as
possible for centos-regression, netbsd-regression, regression with
multiplex, and glusto tests.
- Clarifications on 3.13 (STM), 4.0 (STM), 4.1 (LTM)
- Current calendar is 2 months between 3.13 and 4.0.
- [Amar] No features for 3.13 proposed yet. Nothing proposed yet
- [Shyam] 3.13 may be a sneak peak into 4.0 as features for 4.0
land at the time of branching.
- We should plan to take in Gfproxy into 3.13. If we can get it in
early, we can stabilize messaging around Gfproxy. Poornima’s
- Poornima has updated github issue with latest status.
- Amar is considering error codes for 3.13 since there’s 2 months
as well. At least an early version given nothing changes from
user point of
view. Not committing given large code change and review effort.
- Rafi: Halo can be taken in. Amar: Halo is already in. Rafi:
Looking at the patches that FB has in their branch specific to Halo
replication. This is already in and can be highlighted as a feature to
3.13. (Already landed in 3.11).
- Kotresh: Also useful to have a use-case defined for Halo
replication vs geo-replication. Vijay: When Halo is
available, we will need
to update our documentation for different types of
replications we provide.
- 4.0 is slated for January 2018. Early Jan but worst case late
Jan. Features are already planned. We have to discuss how to
get them in
early and what support those developers will need. During the
need to do an off-hand check with maintainers about what they need.
Possibly Thursday night?
- Expectations from maintainers:
- Scope clarity: 4.0 milestone on Gihub has 50 features listed.
When you mark an issue for 4.0 milestone, send an email with
link to issue.
There’s 50-ish features. We’re 5 months away from the
release. Can we ship
them all? Would be nice for maintainers to look at their
components to see
what can happen. If we can’t ship them, then please remove
them from the
milestone, so we’re clear what can make it.
- Status of features: Good to have status update on big features
so we know what’s going on.
- What help do you/others need: As we get nearer to the release,
Shyam picks reviews that are connected to major features and
reviews for it. Please help with this process and if you’re
help with prioritizing reviews as well.
Improving Quality of releases
- Baseline and do better on coverage reports: As we add more code, we
want our coverage to improve. We’d like maintainers to look at their
component and improve their coverage. Or at the very least not decrease
coverage. We want to target this for 4.0. As pre-requisite for release.
- Same as above for coverity
Let’s set baseline and bring down the number of issues. We have 848
coverity failures at the moment, how do we set targets to bring
it down. We
need to set baselines at release time and assign ownership for components
which need to improve. Release team will send out reminders about this
focus and provide call outs as a release gate.
- New features, plan to address regression tests and coverage are
needed: We’re adding a bunch of new features. We cannot have tests as
hindsight. When these features land, we need healthy test coverage. We
should *plan* for higher coverage of new features as they land and at
least before branching.
Additional release owners for 3.13 and 4.0
- [Amar] Can help in follow ups
- Anyone interested can contact Shyam
How are we tracking changes in 3.8-fb branch? Should maintainers see
whats useful? or should we followup with FB on when it would be sent to
- [Ravi] What is facebook’s stragety for contributing patches to master?
- FB has completed upstreaming it’s patches to release-3.8-fb. About
98%. They’re keep to get these patches into master. Since
they’re not keen
to carry these patches in their fork. They intend to do an accelerated
forward port to master around December. At this point, we will
to review their patches and accepting.
- Around 3.10 we called this out, there are patches in 3-8-fb branch.
If you could monitor it and port patches into master, that would be good.
These are fixes that would be good to have for us too. Retain
so that we track that the patches are ported.
- If the fix is the same, but we take a different approach, what do
we do? Like every project, let’s do the change and invite them
Some of the Halo fixes, the patch description doesn’t help
it’s trying to fix. Email/add them to patches. If they don’t
talk to FB during the fortnightly sync ups.
- 4.0 branching is around early December. We will be busy around the
same time. FB only has time around early December, we cannot change that.
- GD2 -
- Need maintainers to help with options changes.
- Currently you can create a volume, start a volume and mount a
client in glusterd.
- The framework for making it generic with volumegen and volumeset
isn’t complete yet. That will land later this month. That’s
where they need
maintainer help. GlusterD will not maintain it’s own options
translators which provide options need change with new flags
- After volumegen patch gets in, we’ll move to georep and other
plugins. Aravinda has send a patch to change the way georep
written. Working towards getting snapshot and quota team to talk to
glusterd2 team so they can have plans for these changes.
- Protocol changes.
- [Amar] From this month onwards, few members of team will spend
at least one day on Gluster 4.0 activities per week, in the BLR office.
- Mostly working on protocol changes next week.
- initial patches sent for review
- Will be broken into multiple patches, will need help.
- GFProxy -
- updated status available at
- Error codes -
- Initial changes are in, needs a lot of reviews
- Part of hackathon at Bangalore for later weeks.
- [Shyam] Update mail in progress, should hit the lists by this
- [Nithya] Upstream gluster documentation work, need help from all
- [Vijay / Shyam / Amar] Very critical, please extend help.
- [Shyam] Release retrospective for 3.12, please do talk about things
that can be improved
- [Vijay] Welcome Xavier as full time Gluster contributor. Glad to
have you onboard in Red Hat Gluster team.
- [Vijay] FOSDEM, DevConf discussion are on, will hear more in the
future on this
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the maintainers