Skip to content

Maintainters Meeting Notes Archive

Jump to bottom Edit New page
Nigel Babu edited this page Apr 17, 2018 · 2 revisions

Gluster maintainer meeting notes

Meeting date: 03/07/2018 (March 3rd, 2018. 19:30IST, 14:00UTC, 09:00EST)

BJ Link

Attendance

  • [Sorry Note] : Atin (conflicting meeting), Michael Adam, Niels de Vos,
  • Amar, Nigel, Jeff, Shyam, Kaleb, Kotresh

Agenda

  • AI from previous meeting:

    • Email on version numbers: Still pending - Amar/Shyam
      • Planning to do this by Friday (9th March)

  • can we run regression suite with GlusterD2

    • OK with failures, but can we run?
    • Nigel to run tests and give outputs

  • Line coverage tests:

  • Gluster 4.0 is tagged:

  • Gluster Infra team is testing the distributed testing framework contributed from FB

    • [Nigel] Any issues, would like to collaborate
    • [Jeff] Happy to collaborate, let me know.

  • Call out for features on 4-next

    • should the next release be LTM and 4.1 and then pick the version number change proposal later.

  • Bugzilla Automation:

    • Planning to test it out next week.
    • AI: send the email first, and target to take the patches before next maintainers meeting.

  • Round Table

    • [Kaleb] space is tight on download.gluster.org * may we delete, e.g. purpleidea files? experimental (freebsd stuff from 2014)? * any way to get more space? * [Nigel] Should be possible to do it, file a bug * AI: Kaleb to file a bug *

    • yesterday I noticed that some files (.../3.12/3.12.2/Debian/...) were not owned by root:root. They were rsync_aide:rsync_aide. Was there an aborted rsync job or something that left them like that?

    • most glusterfs 4.0 packages are on download.g.o now. Starting on gd2 packages now.

    • el7 packages on on buildroot if someone (shyam?) wants to get a head start on testing them

    • [Nigel] Testing IPv6 (with IPv4 on too), only 4 tests are consistently failing. Need to look at it.

Meeting date: 02/21/2018 (Feb 21st, 2018. 19:30IST, 14:00UTC, 09:00EST)

BJ Link

Attendance

  • [Sorry Note] : Atin (conflicting meeting)
  • Kaleb, Nithya, Ravi, RaghuG (logging off in 20 min), Sunny, Amar, Deepshika, Shyam, Sunil, Aravinda, Xavi, Kaushal

Agenda

  • Gluster 4.0 - release:

    • GD2: Packaging
      • Fedora dependency handling. 4 done, few more in pipeline
      • Tarball on Thursday (2/22) - Should be possible
      • AI: [Kaushal] Update status on Monday to keep risks known
    • All good with release notes?
      • Individual owners to act upon perf section [raghug]
      • Need to start on GD2 [kshlm]
      • [RaghuG] Sent out the email
      • AI: [Shyam] Complete release notes for RC1, minor edits can come in the last week
      • AI: [Kaushal/Aravinda] Need GD2 release notes from the team, By Friday
    • Testing done?
      • AI: [Shyam] RC1 based upgrade testing to be done
      • Awaiting perfomance testing results
      • Glusto has issues running with 4.0, so not happening for this release!
      • [Ravi] Rolling upgrade testing is working
      • [Kaleb] built Ganesha server/gfapi: basic stuff worked
    • Any risky components?
      • Tiering? (call this feature/xlator phases, can confuse wng feature :) )
      • Impact of cluster.force-migration on remove-brick operations, is a possible blocker
    • RC1 dates and blockers
      • Dates: ASAP to facilitate upgrade testing and packaging with GD2
      • Blockers:

  • Releases in future - A proposal:

    • Keep the time of the release predictable
    • No tieing of feature to a release
    • No more STM (ie, better to do the tiering in code than STM release)?
    • Every release is supported for 1 year (with backports for fixes etc)
    • Make release numbers move out from x.y.z to yy.mm.dd format ? (Or any other format too is fine)
    • Have 3 releases a year, 4 months apart — [Atin] I’d like to understand what’s the drawback with the current model which makes us to think on this direction?
    • [Shyam] Intention is not to break Backward compatibility
    • [Aravinda] Does it increase branches to backport to?
      • Remains as 3 (N, N-1, N-2)
    • [Ravi] So does this mean update releases do not happen?
      • No, update releases are still monthly, with exception updates any-day for critical fixes!
        • I would like to see the update releases go to a two month cadence if we're going to keep maintaining three releases. Packaging! (usual exception for critical fixes) --kaleb
    • [Sunil] How do we address major changes in a release to the community (for example things like GD2)
      • Release notes, is the manner of updating content in a release
      • final Milestone in github issue is another manner of finding out what went where
      • If issue is known, looking at it gives the release version as well
        • Or use search terms to filter the issues
        • and, this remains the same as it is now!
      • Major changes need to be announced early and time to deprecate older way to do things should also be announced
    • [Aravinda] Date based versions can cause confusions
      • [Shyam] I am in favor of incremental release numbers like Fedora, instead of date/time.
    • AI: [Shyam] Announce changes to maintainers (today) -> By next Tuesday seek feedback from Users -> 2 weeks hence announce and change the web page to reflect new scheme (and other work in this regard)

Meeting date: 02/07/2018 (Feb 07th, 2018. 19:30IST, 14:00UTC, 09:00EST)

BJ Link

Attendance

  • [Sorry Note] Shyam, Atin, Amye, Niels (meeting conflicts)
  • Nigel, Amar, kshlm, Xavi, Aravinda, Kotresh, Sunny, Deepshikha, Nithya, Milind

Agenda

  • Action Items?

    • Emails on Regression Infra change proposal [DONE]
    • NetBSD - Smoke no longer voting [DONE]

  • Gluster 4.0

    • Second last meeting before release
    • GD2
      • [Kaushal] Need to get us accepted into Fedora. Asked us to undbundle dependency. Most dependencies are via etcd, but since etcd is packaged, the deps are packaged. We'll need to package at least 3 packages.
      • Pretty simple work to do. Kaushal will be maintaingin GD2 packages
      • Fedora bug for reference.
      • Kaushal working on updating the spec file.
      • [Aravinda] Integration with other gluster features is ongoing. Some patches merged and some are pending review.
      • GD2 releases will be concurrent to gluster RC releases. Release notes and docs need work.
    • FS features
      • [Amar] Date for cut off is already gone. Most features are already in.
      • If anything is open, please talk to Shyam.
    • Release Notes
      • We've committed the skelton for the notes. If you are expected to fill in the notes, please help fill it out.
      • We want to make a press release for 4.0. Please provide content for the PR.
        • Post about new features
        • New montioring related features
        • GD2 testing
        • Generally more content online that can be picked up by the press.
    • Containers images roll-out with packages
      • We want to provide container images for Gluster publicly with 4.0.
      • Humble offered to take care of container images for Gluster.
      • We should help test it since as soon as its out, people would start using it. Would tarnish our reputation if they don't work.
      • [Kaushal] They should be run with Kubernetes or openshift, not directly. Kaushal will try to test, but cannot guarantee to spend time.
      • We should make the documentation clear. Amar will ask Humble to write the initial draft for docs.
    • Upgrade guide requirements
      • Specially, for node OS upgrade scenarios (CentOS6->7)
        • We will need to provide proper documentation.
        • EL6 will have client.
        • We could potentially provide packages via download.gluster.org for EL6 using Go compilers from software collections.
        • Need to cover possible cases like geo-rep in addition to basic volume types
        • There's a few xlators we need to support. If there's anything known as issues with Centos6, please raise concerns now.
    • Any other repository needs releases?
      • If you own a gluster project which needs a release for 4.0, please make sure you release in sync with 4.0 to clearly point out which version works with 4.0
      • gluster-block
      • glustermetrics
      • heketi?
      • Anything else? Check https://github.com/gluster/
    • Go/NoGo panel for the release?
      • You have to review all patches taken in after branching and help with testing
      • Suggestion: Kaleb/Niels, Amar, Shyam, Kaushal, +2 other volunteers
      • [Amar]: We probably need one more person from GD2 team since there are a lot of changes and gd2 is our major feature for 2.0
    • RC0/1 testing and participation
      • Glusto: Nigel will run Glusto test runs.
      • Perf testing: We need volunteers especially since Meltdown/Spectre related questions will be around.
      • Other(?): If someone can check line coverage, that'd be great.

  • Infra update

    • regression migration to CentOS7
      • Going on smoothly (Tests are being run on CentOS7 partially already)
      • Majority is shifted to CentOS7.
      • Any machine with pattern 'builder1NN.*' are of centos7. Anything which is 'slave' would slowly go away.
      • 'release' branches needs to shift to centos7 later, as still some tests are failing.
      • Mostly should help by rebasing to latest on the release branch.
      • With migration to CentOS7, tests are taking only 3hr 30mins, instead of 6hrs. And also the intermitent failures are reduced to almost 0.
    • NetBSD
      • No response to our emails, taking that as 'No one is interested to maintain it at the moment'

  • Roundtable

    • No updates

Meeting date: 01/24/2018 (Jan 24th, 2018. 19:30IST, 14:00UTC, 09:00EST)

BJ Link

Attendance

  • Kaleb, Ppai, Nithya, Shyam, Nigel, raghug, Sunil
  • [Sorry Note] Amar, Atin (conflicting meeting)

Agenda

  • libtirpc in RHEL and CentOS [kaleb]

    • Fedora 28 (rawhide) and other leading edge distributions are using newer glibc with rpc headers and rpcgen removed. They are telling people to switch to libtirpc
    • Issue: RHEL/CentOS have old libtirpc without xdr_sizeof(), and in the case of RHEL6/CentOS6 even older without xdr_uint32_t() and xdr_uint64_t().
    • Would we want to have CentOS Storage SIG use a private build of libtirpc? There is a precedent this: the Storage SIG uses a private build of userspace-rcu. And maybe RHEL (and thus CentOS) would update to a newer version eventually?
    • Action: Take this discussion to the mailing list. Needs input from stakeholders as well
    • Jeff will check which version of FB they run.
    • We should be running one rpc library if possible.

  • 4.0 Plan details

    • Proposed detailed plan here

  • GD2 packaging

    • [Decision] We're going with subpackage instead of separate package for 4.0.

  • Wireshark changes

  • Retiring Centos6

    • feasibility of client on centos6
    • [action] Shyam to start a thread

  • Retiring NetBSD

    • No comments on the email thread yet
    • If nothing comes up, Shyam to file bug to disable NetBSD.

Meeting date: 01/10/2018 (Jan 10th, 2018. 19:30IST, 14:00UTC, 09:00EST)

BJ Link

Attendance

  • [Sorry Note] Misc, Amye, Atin (conflicting meeting), Ravi
  • Amar, Nigel, Shyam, Kaleb, Nithya, Kotresh, Csaba, Xavi, Kaushal, Aravinda, Raghavendra G

Agenda

  • 4.0 ? Are we good to branch?

    • GD2 : Not a blocker as it is continuing in another repo

      • [Kaushal] Aravinda's Volgen is in. Helps with different volume types.
      • Should also help to get rebalance and heal commands.
      • Planning to have a release this week.
      • Upstream glusterfs master works with GD2 (or GD2 works with master)
      • [Shyam] RC release packaging requirement? What do we need?
      • [kshlm] Need golang on build system. Some more changes in Makefile and build scripts. Other than that don't see much issues with RPM building.
      • Building tarball with all dependencies also may be needed.
      • Tarball will contain all dependencies. Fedora may have issues. Have to check with Niels about CentOS.
      • AI: Shyam to start mailthread about this with package maintainers.
      • Need a quickstart guide - Current guide. Present. Need some more data there. And feedback.
      • [kshlm] provide recovery steps for whole cluster goes down.
      • [Amar] Need a release and quickstart guide on priority.
      • [Shyam] A week after branching is good time

    • [Atin] Changes for making GD2 understand options across all the xlators are not yet complete. Would that become a blocker for branch out?

      • [Shyam] Is it blocker? Looks like it is not blocker, may be allowed to be bug fix post branching. But loosing momentum is a concern.
      • [kshlm] Fine with it as its only GD2 which consumes it.
      • AI: Shyam to mention it in email about 4.0 branching.

    • Protocol : Plumbing done, regression failures being debugged. Need another week to have it ready. (See https://review.gluster.org/19098.)

      • From today, not after branching
      • AI: check with Wireshark changes need to be done by 4.0 release
      • No need to define futurist fops now.

    • CentOS6 support in 4.0?

      • [Kaleb] Concerns with Python/GoLang issues, mostly
      • [Kshlm] gd2 doesn't build on centos6. may work on epel.
      • [Nigel] We are ready to move to centos7 on regression. No dependency on centos6.
      • [Shyam] Is there a concern from centos SIG? [Kaleb] No.
      • This is a community question.
      • AI: Need to be checked with community and any downstream concerns for people.

    • NetBSD support in 4.0?

    • Other features as tracked in the github lane for 4.0 [Shyam]

    • Review focus for patches targetted for 4.0 [Shyam]

      • AI: To send a email to start focused reviews.
      • Surely need focused effort here, with priority.

    • Kaushal is speaking at FOSDEM and DevConf - 2018 about Gluster-4.0 GD2.

      • Will reach out for reviews of presentation

  • Current failures of centos6 regression failure?

    • [Kaleb] Random failures happening right now
    • [Jdarcy] Can you paste the link? Here
    • [Nithya] Is it rebased after ssl revert?
    • [Aravinda & Kotresh] There were failures on geo-rep test cases, and now mostly fixed. Thanks to Nigel.
    • [Nithya] Is it timing related? has the spectre & meltdown patches gone in ? [Nigel] Yes, they are all updated.
    • [Kaleb] Patch is just about linking libraries (in makefile), but no code change. Treat it as showstopper, for branching.
    • [RaghuG] See some ABORT errors [NigelB] All of them were about timeout, bumped up the timeout.
    • [Nigel] AI: Can consider changing the provider.

  • Upcoming infra changes

    • [Nigel] Background story: to be short, no more funding from current provider, and is costlier for the requirement we have.
    • We're working on moving from a static infra to dynamic test infrastructure.
    • We're also switching providers. Currently evaluating new providers
    • This move will help us create nodes for chunked regressions on-demand and throw them out after the job is done.
    • The test framework and how we log test failures will undergo significant changes due to this.
    • I will be pinging some maintainers this week to debug test failures.
      • NFS failures currently (2 of them) jdarcy to take a look at gNFS.
    • https://build.gluster.org/job/cage-test/180/console
    • This is the time to talk about NetBSD and our future support for NetBSD.
      • Again, a community call.
      • [Jdarcy] when was the last time we heard from Emmanuel? [Someone] At least a year?
      • Looks like freebsd is similar with compatibility issues compared to netbsd. In that case, please go for it.
      • [Shyam] Who would be maintainer if we move to freebsd?
      • Treat it as best effort? Get help from community?
    • Console output is a current issue of moving to new provider.

  • Long term roadmaps? What is our plan?

  • Automation document - Any further comments?

    • AI: take it to mailing list, and Nigel is happy to do it 👍

  • FYI, Launchpad build farm is offline. No ETA for when it will return. Ubuntu 3.10.9 packages are queued to be built as soon as it returns online

Decision(s)

  • AI: Shyam to start mailthread about this with package maintainers.
  • [Nigel] AI: Can consider changing the provider. Also talk about regression failures.
  • AI: check with Wireshark changes need to be done by 4.0 release (after the protocol change)
  • AI: Need to be checked with community and any downstream concerns for people, for retiring support for centos6.

Meeting date: 12/13/2017 (Dec 13th, 19:30IST, 14:00UTC, 09:00EST)

BJ Link

Attendance

  • [Sorry Note] <Add your name if you can't make it>
  • Nigel
  • Amar
  • Atin
  • Nithya

Agenda

  • Any AI from previous meeting?
    • None

Decision

  • Less people in meeting, and hence decided to not pick up any topic
  • Decided to move out the 'automation' part of the agenda into another document, and move it out to email instead of meeting. Other things can be discussed later.

None Below got discussed

  • 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]
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, their github label setting access can be revoked. No issues with 'maintainership' of glusterfs project as such.
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.
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!
    • Make parallel / chunked tests a reality

  • More Automation on Bugzilla state transition:

    • Today, it is expected of developer to mark a bug as POST, MODIFIED etc, it can be automated similar to github's updates #issue and fixes #issue.

  • Automate cherry-picking to release branches

    • can we have something like rebase to $branch as a review commit command for jenkins, which does the cherry-pick etc?

Round Table

  • [Amar] Do we need a STM release in future? ie, after above process is done.
    • Looks like STM's main goal was to say that 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.

Decisions

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

BJ Link

Attendance

  • [Sorry Note] amye, Atin (conflicting meeting)
  • Shyam, Amar, Nigel, Ravi, Jeff, Soumya, kaleb, Xavi, kaushal, Rafi,

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.

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

BJ Link

Attendance

  • [Sorry Note] misc, Atin (Conflicting meeting), Csaba
  • Amar, Nigel, Nithya, Xavi, Ravi, Mohit Agrawal, Shyam, Deepshika, Kaushal, Niels (late, BlueJeans--)

Agenda

  • Action items from last meeting:

    • [nigelb] Metrics on first-time contributors?
    • [nigelb] Cregit run?
      • Both to be tracked as bugzilla bug, request queue full atm.

  • Re-visiting closing old reviews [nigelb]

    • Using Gerrit to do the initial closing is a bad idea.
    • We have a lot of reviews and each abandon triggers an email to everyone involved.
    • This means Gerrit server will get greylisted by all providers as we did for stage recently.
    • We have a Jenkins job that will close a few old reviews every day. Currently thinking of 25 per day. Once we catch up, we can either continue with the bot or use Gerrit to do this.
    • Is the plan sounding fine?
      • Yes
    • Review: https://review.gluster.org/#/c/18734/

  • Release sanity [nigelb]

    • We run regression-test-burn-in for master.
    • We don't for release branches. Seems like a no-brainer to do this.
    • However, this will add load onto regression machines 1x number of active releases per day.
      • This occupies machines, should we run such things once daily, so that we can keep regression machines free?
        • Are we not moving towards reducing regression time, so this is not a problem?
        • Need more regression machines to pull this off
        • Move the job to Eastern TZ (mid-day or later) as that is a relatively free of regression jobs zone.
        • More patches in one job, means finding out what caused failure would be more difficult
          • This possibly can be handled using git bisect and other such.
    • Options to mitigate
      • We will trigger a regression run only if there are changes since last run.
      • Shall we move regression-test-burn-in to nightly?
      • We (release-owners) need the ability to trigger this job, so that a release can be made (releatively) deterministically [Shyam]

  • Jeff's email on Pressing 'Submit' if everything is OK?

    • What is stopping you from doing it?
      • Assumption is that maintainer of the component merges the patch
      • Not focussing on the patch backlog due to other constraints
      • Xavi is taking good initiative here, need more of the same
      • We need a catch all case when patches are not moving, than depend/rely on maintainers always
      • Components in the fringe are often ignored, and need attention (for example hooks or such)

  • Regression Suggestion:

    • Should author wait for at least one sanity review before running regression?
      • Current regression takes time, so not running on local machines
      • Sometimes reviewers see patches only post a regression score
      • People trigger regression before smoke finishes, which is bad! (when smoke fails)
        • Should we pipeline this, regression only if smoke passes. This may lead to some trouble with voting, needs a bit of expperimentation.
        • This could be a problem in terms of people running random code on our tests.
      • Release branches is better to get regression votes before review, as release-owners may need to review and merge in the window that they work with the branch/release [Shyam]
      • Decision: Not yet! (wait for regression jobs to run faster)
    • Will save some cycles as I have seen authors doing '+1' to verify immediately, and then they get -1.
    • Makes sense if their patch gets reviewed just after smoke (or even without smoke +1 too)
      • [Atin] I have a disagreement of author to wait for review before marking the patch verified +1. To me, it's author's responsibility to ensure the basic regression is passed and that way maintainers get a confidence on the sanity of the patch. As a GlusterD & CLI maintainer, most of the times I look at reviewing patches (in 90 - 95% cases) which have passed regression.

  • 'experimental' branch rebase

    • Major conflicts with posix changes :-/
      • Shyam to blame :/
      • AI: Shyam to sync with Amar and get this moving (Shyam)
    • Other option changes which GD2 was dependent on, is sent to master with --author set to original authors.

  • 4.0 Schedule [Shyam]

  • Round Table:

Decisions

  • Jenkins job to retire older reviews: Ack to do this, in batches
  • regression-test-burn-in for release branches: Ack
  • regression-test-burn-in on demand for release branches: (I think this was an Ack from Infra folks)
  • regression-test-burn-in for master moved to nightly (close to mid-day easter TZ): Ack

Meeting date: 11/01/2017 (Nov 1st, 19:30IST, 14:00UTC, 10:00EST)

BJ Link

Attendance

  • [Sorry Note] Jose, Atin (Holiday in India)
  • jdarcy, shyam, amarts, amye, nigelb, michael (misc), ndevos (DST failure)

Agenda

  • Gluster Summit Updates

    • How to handle first time users properly, so they continue to contribute more?
      • AI: Report generation to identify first time contributors in the works [Nigel]
    • Handling the patches if more than 10 revision happen in a patchset?
      • "Patch etiquette" documentation (jdarcy)
      • AI: General agreement on this process is present, we need to document and share the news to the larger contributors lists
    • Feature deliverables diligence enforcement [Shyam]
      • A feature should not be commited to code without,
        • Sufficient design
        • Documentation updates
        • Relevant test cases
      • Maintainers would be reponsible to ensure all deliverables are in place before the merge
      • All deliverables can be tracked in the github issue for the feature
      • Please! no more slips of features masking as bugs
      • Should we extend test cases for bug patches as well, noting in the review if an exception is taken for a bug commit without a test case?
      • Discussion:
        • Can we keep the github issue open till all deliverables are met and use some flags there, like BZ
          • Possibly not, as folks post code submission, do not revisit the github issue
        • Documentation versioning and handling this with that request
          • There are challenges here, repo versions, search, and such in maintianing versions
        • AI: Continue this on the maintainers list and decide on further course of action [Shyam]
    • Further updates if any?
    • Infra Updates:
      • Jenkins now runs on Centos 7. The downtime is not yet complete.
      • We're going to also move bits.gluster.org onto a new server today.
      • If all goes well, this deprecates the old Jenkins server which a lot of people had SSH access into.

  • Gluster 4.0

    • mass reformat to improve consistency (jdarcy)
      • git history can get mangled (cregit tool can help maybe)
      • Ex: cregit.linuxsources.org/
      • AI: [Nigel] to check and see if history mangling can be avoided with the above tool
      • AI: [Shyam] add to 4.0 plans mails
      • AI: [Jeff] Provide an example that can help assess work
    • Release tasks update [Shyam]
      • Post 3.13 branching, master is open to absorb all of 4.0 goodness!
      • We need to ensure we call out the features that are going to make it, as branching deadline for 4.0 would be mid-december considering end Jan release!
      • 3 months from 3.13 is end Feb, but we have decided end Jan as 4.0 is also an STM
      • Features/Major changes:
        • GD2 is a big piece and needs some decisions there
        • Protocol changes
        • Monitoring changes
        • FB Changes
      • AI: [Shyam] to start threads on the list to get things moving

  • Round Table

    • Suggest adding "Decisions" section to document, that calls out decisions made [Shyam]
      • AI: [Amar] to try and incorporate this into the notes
    • Summit video recording to be uploaded and made public
      • AI: Do we have all the slides? [Amye]
      • AI: BoF summary mails reminder to the owners [Amye]
    • gNFS maintainers announcement [Shyam]
      • AI: To be done in a day or two, adding Shreyas and Jeff from Facebook to the MAINTAINERS file [Shyam]

  • Decisions:

    • Minor modifications to patches from maintainers is OK if below is properly followed-up:
      • Author information remains intact. (Use 'git --author' option)
      • Original Author is notified with clear reason for edits:
        • Can be "I like the idea, and would like to land it in next release as I feel its important, would like to make minor modifications to some log-messages and send a patch myself on your behalf to cut down the time. Thanks, sincerely"
        • Or "I like this idea, and don't see much activity on this from last few weeks. If you don't mind I am planning to resend it on your behalf for the review".
        • etc, etc.

Meeting date: 10/17/2017 (Oct 17th, 19:30IST, 14:00UTC, 10:00EST)

BJ Link

Attendance

  • [Sorry Note] Niels, Atin
  • raghug, Amar, Kaleb, Michael Adams, Nithya, Shyam(joined late),

Agenda

  • AI from previous week

    • Coding standard (if time permits) https://review.gluster.org/#/c/17651/

      • AI: Maintainers please review, add all maintainers as reviewers [Mostly Done, Good to merge]
      • Possibly add Go coding standards [Kaushal - Not Done yet]
        • Would be good to have it by the time of merging of GD2 to mainstream

    • 3.13 -> 4.0 Additional quality tracking [Pending Votes]

      • Reduce overall coverity defects/issues
      • Improve on code coverage across each component
      • Glusto runs should pass
      • All components not meeting above guidelines will block the release, and hence need attention
      • The base line will be compared to 3.12 and announced just post branching for 3.13, giving teams 6 weeks to meet the required targets
      • Future releases, may track an actual %age increase/decrease in the metrics
      • Thoughts?
        • Get more tests into Glusto, mandate this in 4.0
          • AI: Check back with Nigel and see if Glusto code coverage metrics can also be gathered [Shyam]
        • Accept: Shyam, Amar, Nigel,
        • Reject:

  • Gluster Summit

    • Any specific off-hour meetings?

      • Error code finalizing (issue #280)
      • Protocol changes. Email has some responses, but need a list made and agreement on implementation.
      • Should we have Technical Leadership committee ?
        • It was proposed in one of the earlier maintainers meetings. Do we need it to pursue it further?
      • gfproxy? GD2?
      • Experimental Demos? : RIO / cgroups effort / etc etc..
      • Samba performance
        • Discussions on how different caching layers are used etc..

    • Would be great to have a plan on long term goals, say more than year.

    • [Kaleb] Plan on coverity, memory leaks and other issues, how to reduce them.

  • Gluster 4.0

    • Review backlog piling up. Need help

  • Round Table

Meeting date: 10/04/2017 (Oct 4th)

BJ Link

Attendance

  • [Sorry Note] Amar, Michael
  • Shyam, Milind, Kaleb, Atin, Niels,ppai, Jiffin, csaba, Sunil, Rafi KC, Xavi, raghug, Vijay, Nithya

Agenda

  • AI from previous week

  • Gluster Summit

    • Plan meetings now, convince people with your ideas, get it done :-)
    • Any concerns on big changes, have it clarified in person (if possible)
    • Plan long term goals (ie, what is 5.0 etc etc) - Any free slots (due to issues with travel etc), who will have extra talk ready? - unknown yet, I haven't had anyone cancel their talks yet. -- amye
    • AI: Can we get a sheet where folks can share travel plans? [Jeff -> Amye]

  • Gluster 4.0

    • Some update emails sent
      • GD2
        • Volgen code in progress, and possibly will be done this or early next week
        • Some top issues are w.r.t 2 node cluster and quorum loss
        • When would this come into master?
          • Now that volgen is almost ready, what is the plan? [Atin/ppai/Kaushal]
          • ppai prefers glusterd2 to continue development as separate repo
    • Review backlog piling up. Need help
    • [Atin] Do we have users using tiering feature? Do we need to keep on supporting tiering in 4.0?
      • We have not announced it as stable upstream
      • Even calling it tech-review/experimental will need GD2 support
        • We possibly ask folks to use GD instead of GD2 if they want to try out Tier, is an option
        • AI: [Amye] Possible survey question!

  • 3.13 -> 4.0 Additional quality tracking [Shyam]

    • Reduce overall coverity defects/issues
    • Improve on code coverage across each component
    • Glusto runs should pass
    • All components not meeting above guidelines will block the release, and hence need attention
    • The base line will be compared to 3.12 and announced just post branching for 3.13, giving teams 6 weeks to meet the required targets
    • Future releases, may track an actual %age increase/decrease in the metrics
    • Thoughts?
      • Get more tests into Glusto, mandate this in 4.0
        • AI: Check back with Nigel and see if Glusto code coverage metrics can also be gathered [Shyam]
      • Accept:
      • Reject:

  • Options to track FB patches from 3.8-fb branch [Shyam]

    • Here is a look at the current status of patches posted by FB in release-3.8-fb branch
    • Here is a tracker to generate the same report
    • Further actions/intentions
      • Patches here are bug fixes and features, and can help the code base attain better stability
      • Intention from the community should/could be to actively participate in forward porting these to master
      • Actions hence are, to encourage, track/discuss and forward port, the changes pertaining the areas of maintaner responsibility

  • Round Table

    • Facebook has offered to maintain gNFS in our tree, as it is one of their primary server protocols in use. As Gluster stance is to move to Ganesha in light of NFS support, we would like to accept FB's offer in light of continuing NFSv3 support for interested users in the community via gNFS, what this means,
      • gNFS is still maintained
      • gNFS is an option for users
      • gNFS is not taken out of the tree, not built etc. for 4.0 or later
      • Facebook contributors Shreyas and Jeff would get added as maintainers
      • Thoughts/comments?
        • Do we know how many users are on gNFS? We think most are on gNFS, we may have some date from the previous community survey
          • AI: [Amye] Possible survey question!
        • Code will still be in the tree, this was not going to be removed anyway [Kaleb]
    • Coding standard (if time permits) https://review.gluster.org/#/c/17651/
      • AI: Maintainers please review, add all maintainers as reviewers [Shyam]
      • Possibly add Go coding standards [Kaushal]

Gluster maintainer meeting notes

Meeting date: 09/20/2017 (Sept 20th)

BJ Link

Attendance

  • [Sorry Note] mscherer, kshlm, atinm, amye
  • Amar, Rafi, Nigel, Milind, Nithya, Kaleb, Shyam, Xavi, Ravi, raghug, vbellur, Kotresh

Agenda

  • 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? (netbsd/netbsd-brick-mux?)

    • 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/basic/distribute/rebal-all-nodes-migrate.t
      • tests/features/delay-gen.t
      • 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.

  • Release roadmap

    • 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 latest patch passes regression.
      • 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 summit, we 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 chase down reviews for it. Please help with this process and if you're being chased, 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 'master'?

    • [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 maintainers 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 the change-Id 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 to comment. Some of the Halo fixes, the patch description doesn't help understand what it's trying to fix. Email/add them to patches. If they don't respond, we'll 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.

  • Gluster 4.0

    • 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 table. All translators which provide options need change with new flags and default values.
      • After volumegen patch gets in, we'll move to georep and other plugins. Aravinda has send a patch to change the way georep configs are 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.
    • Monitoring
      • initial patches sent for review
      • Will be broken into multiple patches, will need help.
    • GFProxy -
    • Error codes -
    • RIO
      • [Shyam] Update mail in progress, should hit the lists by this week

  • Round Table

    • [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.

Meeting date: 09/20/2017 (Sept 20th)

BJ Link

Attendance

  • [Sorry Note] mscherer, kshlm, atinm, amye
  • Amar, Rafi, Nigel, Milind, Nithya, Kaleb, Shyam, Xavi, Ravi, raghug, vbellur, Kotresh

Agenda

  • 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? (netbsd/netbsd-brick-mux?)

    • 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/basic/distribute/rebal-all-nodes-migrate.t
      • tests/features/delay-gen.t
      • 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.

  • Release roadmap

    • 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 latest patch passes regression.
      • 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 summit, we 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 chase down reviews for it. Please help with this process and if you're being chased, 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 'master'?

    • [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 maintainers 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 the change-Id 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 to comment. Some of the Halo fixes, the patch description doesn't help understand what it's trying to fix. Email/add them to patches. If they don't respond, we'll 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.

  • Gluster 4.0

    • 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 table. All translators which provide options need change with new flags and default values.
      • After volumegen patch gets in, we'll move to georep and other plugins. Aravinda has send a patch to change the way georep configs are 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.
    • Monitoring
      • initial patches sent for review
      • Will be broken into multiple patches, will need help.
    • GFProxy -
    • Error codes -
    • RIO
      • [Shyam] Update mail in progress, should hit the lists by this week

  • Round Table

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

Meeting date: 09/06/2017 (Sept 06th)

BJ Link

Attendance

  • [Sorry Note] vbellur, atinm, nithya
  • raghug, amarts, jiffin, nigelb, ravi, kaushal, pranith, csaba, ndevos, rafi, milind, amye, poornima

Agenda

  • Action Items pending from last week

    • Amar to send changes required for Protocol changes - DONE
    • Nigel & Jiffin to figure out more about ASan builds - DONE
    • Blog posts:

  • patch https://review.gluster.org/#/c/17985/

    • Need more feedback from other maintainers
    • 15days deadline was proposed, 7 days more pending
    • client stack is discussed, concern on brick xlator stack.
    • Reminder to be sent mid-way.

  • Meeting timings

    • Some conflicts with the current time since last month as RedHat moved its program call around same time, where many of maintainers are also part.
    • What other times are possible?
    • We can continue to use this for another 2 months till October, but after that surely need a change which doesn't conflict.
    • For future, we recommend maintainers to consider this slot before agreeing for a recurring meeting at your company, so we can keep this slot static.
    • [NigelB] Can we keep the time same and change the day.
    • [Amye] Happy to read the notes later

  • Any more discussion required on review/patch etiquette?

    • Jeff's email
    • Amar's reply
    • Any more comments? Suggestions for improvements?
    • [Ndevos] Need to have a bug-id instead of RFC if they are indeed a bugfix. Helps a lot with tracking because many of our users are still using bugzilla to track bugs. (Or GitHub Issues, but something trackable.)
    • [Amar] Send the approach to the problem in email if not many are reviewing.
    • [ndevos] can the review comment on merged patches valid in experimental? [Amar] yes, absolutely.

  • Fixing patch dependency

    • Requires a Submit-Type change preferably to Rebase-If-Necessary.
    • We've had this conversation before and recently.
    • What happens if we adopt the Rebase-If-Necessary submit type:
      • No more metadata flags added by Gerrit other than "Change-Id" and "Signed-Off-On"
      • Submit button for dependent patches will be greyed out.

  • Summit - October 27th and 28th

    • Gluster 4.0 - Release leads, life cycle, EOL
    • Discuss: What are the things we need next, to call it Gluster 5.0 ? Time bound? Feature Bound? etc.
    • Release Management Review (what's working and what needs to be better)
    • Infra Planning - What does the community need that we're not supporting
      • Should we do a survey? Do we know what community needs?

  • Gluster 4.0 - Status check

    • GD2 (must have)
      • Minor hackathon @ BLR office. Changes explained.
        • Mail sent out to community - URL
      • Did a demo aimed at developers - URL
      • Plan is to have lot done by summit.
      • [Rafi] What is 'must have'? should it have snapshots etc?
        • Yes, all feature in GD1 should be available
    • Protocol changes (should have)
      • Email sent - URL, need action further
    • gfproxy (should have)
      • Poornima sent the email - URL
    • Error code changes (good to have)
      • Email sent - URL
      • Need a hackathon as it is a lot of code change
    • Monitoring (good to have)
      • Email sent - URL
      • Need to break up the tasks / patches in order so we can make small changes at a time.

  • Round Table (Check with every member, whats' cooking in their domain)

    • [Amye] Please register for summit. It helps to look at funding. Also working on group discount for hotel booking.
    • [Jiffin] nfs ganesha ha solution(storhaug is not yet in full fledge) is not complete
    • [Nigel] Clang/coverity fixes should have a plan to decrease it for future releases.

NOTES

Meeting date: 08/23/2017 (August 23rd)

BJ Link

Attendance

  • [Sorry note]: MAdam, MiSc, Atin,
  • Amar, Poornima, Kaushal, Nithya, Amye, Nigel, Shyam, Vijay, Niels, Milind

Agenda

  • Recap of pending AI from previous weeks:

  • Plan for Gluster Summit 2017

    • Should maintainers discuss anything specific other than Gluster 4.0
      • [Shyam] Operations of project, like what is working good, what can improve etc.
      • [Amye] yes we should that (maintainers BoF)
      • [VBellur] BoF should help to discuss further design discussions in person.
    • Schedule to be released Friday Pacific time
    • Travel deadlines to be announced

  • Release 3.12 Status check

    • Things look good w.r.to patch backlog
    • fstat output: bitrot, gfid resolution in afr (are of concern)
    • all patches which are in 3.8, 3.10, 3.11 are also in branch
    • run glusto on release-3.12
    • RPMs have some issues, Shyam is working with Kaleb on this.
    • AI: Release notes need a review by all, Shyam to send a mail on this [Shyam]

  • Release 4.0

    • GD2 status check
      • CLI peer cmd patch is ready.
      • volgen patches are in work.
      • planned hackathon in RHT BLR office.
      • Should plan a hackathon for community, and give a demo to Gluster Dev community.
      • Provide a good patch which can serve as an example for others to adapt to the newer way of doing things.
    • gfproxy
      • problem is graph switch issues can be of concern.
      • portmapper.
      • gfproxy to run on TSP for now.
      • glusterd2 integration would be critical.
    • protocol changes
      • initial patch is in experimental
      • namelink/icreate fops to serve as an example
    • Round table (on status check)
      • [Shyam]: RIO: working in experimental branch
      • [Shyam]: RIO: posix to be re-used, currently needs a re-ordering.
      • [Shyam]: RIO: working on entry ops, to show a demo at earliest.
      • [Amar]: Error Codes: Very critical, initial work started. Lot of code change, need reviewers soon.

  • Deepshika is now peer on Gluster CI. See https://review.gluster.org/#/c/18091/

    • We don't have a documented process for new peers at this point.
    • We went with both maintainers acking.

NOTES:

Meeting date: 08/09/2017 (August 9th)

BJ Link:

Attendance

  • Amar, Anoop, Milind, Nithya, Susant, Rafi, Vijay, Nigel,Jiffin, Sunil, Shyam
  • [Sorry Note] Jeff Darcy, RTalur, NDeVos, PKarampu, Kaushal, Amye

Agenda:

  • Any more questions about 4.0 discussion? Notes from meeting here

    • glusterd2 is the blocker, with gfproxy and protocol changes

  • Release 3.12? All good? Any concerns?

    • All good. Shyam sent RC mail.

  • Summit CfP

    • Last date is 15th August (ie, before next meeting, so propose talks if any)
    • Any agenda we should focus for Summit? [Specific to Maintainers]

  • Infra update

  • Blog posts

    • Gluster project needs more blogs, and more content in Gluster.ORG
    • See if we can get more blogs at blog.gluster.org
      • 3.12 features?
      • Good to have calendar for this, ie, 1 post per week
      • Need planing and establish list of topics for 4-6 weeks.
      • [Milind] Maybe identifying Use Cases of featiures could help us blog about them about their different aspects
      • Note: Amye wrote a note into the maintainers list outlining next steps and inviting contributions directly after this meeting.

  • Review Concerns?

    • Speak up if you need any support from other maintainers
    • Great if you can update the sheet with URL before the meeting
    • glusterd2 requirements (email response)
    • monitoring metrics (email/code contributions in experimental branch)
    • backport to release branches. Will help to have other people review it too.

  • ASAN builds:

    • How to go forward?
    • [Jiffin] We tried it on NFS Ganesha. Had some issues with Glusterd, but otherwise we found it fine.

  • < Add agenda if any >

Action Items:

  • [Amar] To send a mail on protocol changes for 4.0

Meeting date: 07/27/2017 (July 27th)

Agenda:

  • Notice the change in meeting room from next meeting

    • Moved to auto started / auto recording / separate handle for Maintainers meeting in BlueJeans.
    • Also the meeting repeats on every Wednesday, same time. No need to wait for everyone.
    • Meeting should proceed based on agenda. Make sure to update it 24hrs before meeting, so people have sufficient time to plan for meeting.
    • New meeting URL: https://bluejeans.com/205933580

  • Maintainers 2.0 : Now done, Make sure all maintainers are aware of below.

    • Maintainer access:
      • Should have access to label issues (github)
    • Maintainer responsibilities?
      • Reviews (dashboard request)
      • Design -> github + council
      • Future of component -> github (ideas) -> github lanes
      • Doc (Dev/user/relnotes/best practices/blogs/presentations)
      • Github issues labelling and triaging
      • BugZilla -> ZDP (Zero Defect Pipeline)
        • Ensure a reducing trend in bugs, with the ideal goal being (well!) zero
        • This is not for feature pipeline which is tracked as github issues
      • Testing (glusto/.t/gbench) -> release readiness
        • We're working on having line-coverage tests, which will help us gauge gap in function/components that are not tested. The Jenkins job is currently under testing.
      • Lists
      • Building peers
      • Meetings
        • Be available for the maintainers meeting
        • 2 others, community and bug triaging (this is over email now, see triage guidelines)
      • Release calendar
        • AI: [Shyam] to create a release calendar and share with maintainers@ (this is a google shared calendar), to serve as a quick reference for all
        • How do we get better at release scope? This is an open problem for the community that needs ideas/answers
        • AI: Possibly we get to defining/solving this around the GDS [Nigel]
      • Process for abandoning old patches owned by others
        • Patches get auto abandoned if it is older than 90 days with no gerrit activity (once the flag is turned on. Scheduled to be turned on after the Gerrit upgrade)
        • If a patch has to be revived, reopen it
        • If you want a patch to survive the 90 day mark, add a comment to it!
      • Existing: https://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/
    • Need dashboards and hence feedback for maintainers and peers

  • [Nigel] NetBSD is failing on master

    • AI: [Nigel] Let the job run despite failures
    • Wish list: If we could get the backtrace (like on Linux) would help
    • Who looks at the failures:
      1. Have first responders for NetBSD/all tests
        • Possibly roate them over time
      2. Component/area owners look at failed test cases
        • Possibly difficult to assign and track owners for the test cases that are failing
      • AI: [Nigel] This needs more discussion, take it to the lists

  • 3.12

    • Branching done
    • What next with testing?
      • glusto tests are failing.
      • What was tried for 3.10: issues for testing
      • Make it easier to tests:
        • Provide documentation
        • Write notes on what we specifically want tested
          • Have piecemeal manual tests
          • New features
          • Criticial day 1 activity
          • Upgrades
      • We need to test some regular expectations:
        • Upgrade
        • Standard workloads
        • Existing features

  • 4.0 Status

    • glusterd2
    • gfproxy
    • DHT-RIO?
    • Quality focus?
    • ...
    • Is this a time based release or a feature based release? From a time to release POV
    • AI: [All] Send feature updates to the lists, to keep the momentum and also information flowing to all
    • AI: Setup a separate meeting (time to be synced via email) to discuss this topic [Amar]

  • [Amar] What next with 'experimental' branch.

    • If no one is using it, would like to rebase to master and force push. If people are using, would like to have another branch.

  • [Raghavendra G] What's with Abandoning non-relevant patch.

    • Nigel: Will need a gerrit restart, will do post 3.12

  • [Nigel] Are burn down charts useful for release planning now that we have projects on github? Example

  • Gluster Summit CfP (is this the forum to talk about?)

  • Who will host the next meeting? (Not sure who should host this meeting too :p (I vote for Amar to host this one :) )

Attendance

  • Nigel
  • Shyam
  • Jeff
  • Ravi
  • Kaushal
  • Milind
  • Jiffin
  • Kotresh
  • Rafi KC
  • Amye
  • Michael A.
  • Anoop C S
  • Aravinda VK
  • Niels
  • Susant

Action Items:

  • AI: [Shyam] to create a release calendar and share with maintainers@ (this is a google shared calendar), to serve as a quick reference for all
  • AI: [Nigel] How do we get better at release scope? Possibly we get to defining/solving this around the GDS
  • AI: [Open] Start writing scripts to get the metrics in above bullet points
  • AI: [Nigel] Send to the lists how to generate a gerrit dashboard for a component, with an example
  • AI: [Nigel] Let the NetBSD job run despite failures
  • AI: [Nigel] Who looks at NetBSD failures? This needs more discussion, take it to the lists
  • AI: [All] Send 4.0 feature updates to the lists, to keep the momentum and also information flowing to all
  • AI: [Amar] Setup a separate meeting (time to be synced via email) to discuss 4.0 topic

Meeting date: 06/28/2017 (June 28th)

Agenda:

  • Maintainers 2.0 status
    • Maintainer responsibilities?
    • Patch to change MAINTAINERS: https://review.gluster.org/#/c/17583/
    • Need dashboards and hence feedback for maintainers and peers
    • Nigel needs greenflag on changing the merge rights!
      • To be done on 1st of July - Amar to file a bug
    • Next maintainer meeting will/should/may involve all the new maintainers and peers!!!
  • 3.12/4.0
    • Release calendar shared across all maintainers
      • Google calendar
      • AI: Shyam to create the same
    • Reminder on features mail
    • 3.11 release retrospective feedback
      • Feedback is closed
      • Will hit social media on results
    • Experimental is a bed for accelerting 4.0 features, nightly tests are being planned here
      • Should we have experimental per release?
      • We can decide based on usage and learning from the first few iterations.
    • Nightly pipeline should be ready for 3.12 [Nigel]
      • [Shyam] to sync up on how to monitor this and use it as a gate
  • Let's do release retrospective across maintainers in this meeting.[Nigel] - We can start this from 3.12 [AI: Shyam]
  • 30/90 day review closure [Nigel] - Gerrit configuration change - Needs a gerrit downtime, will be scheduled in the near future (possibly before next maintainers meeting)

Attendence

  • Shyam
  • Amye
  • Amar
  • Niels
  • Nigel Babu
  • Kaleb

Action Items:

  • Start writing scripts to get the metrics in above bullet points
  • AI: Amar to send out a mail to gluster-devel for maintainer2.0 patch and ask everyone review and Ack!

Meeting date: 05/31/2017 (May 31st)

Agenda:

Action Items:

  • AI: All maintainers look at this bug and update Gerrit Filter: https://bugzilla.redhat.com/show_bug.cgi?id=1451184

  • AI: Amar to send out a note about review backlog

  • AI: Team to approve (Ack / Nack) below two proposals:

    • http://lists.gluster.org/pipermail/maintainers/2017-May/002587.html
      • Already responded by Shyam and Vijay, need final confirmation to start progress on this.
    • http://lists.gluster.org/pipermail/maintainers/2017-May/002644.html
      • This is tried in many project as 'feature' branches (earlier tried in case of gluster too)
      • Amar is thinking this as more of a branch which is visible on gerrit, and can be used as a place to test out your idea, and also a place where it can be WIP patches gets merged.
      • This is useful because with patches merged progressively, we allow people to quickly propose their idea to code, and then once all the required patches are in an experimental branch, it gets ported to 'master' branch.
      • Main thing to propose this is, we run weekly regressions and builds from this branch, and we can give our users to 'confirm' if a given feature works for them. Today, either users have to cherry-pick patch, build it themself if patch is not merged and marked WIP.
    • AI: Ack from people attended:
      • Amar to file infra bug to get this moving.
      • Amar to update README and ./rfc.sh of the branch to mention more about the changes.

  • AI: Shyam to send out a condensed github workflow document

    • Pending, TBD before 3.11 release retrospective is sent out (in a week from 31st May)

  • AI: Should the workflow be on the revamped gluster.org website?

  • Maintainers v2.0

  • 3.12/4.0 calendar

    • Features, Testing focus for 3.11
    • 4.0 features/topics are being sent to ML

  • Glusto Status Update [nigel]

    • Glusto in a consumable state by the broader community
    • Shwetha/Nigel to send out an update on -devel
    • AI: set goals for 3.12

  • Coverity covscan [kkeithle]

    • two new issues on master since 2017-04-10 http://bit.ly/2pRGerZ
      • AI: set goals for 3.12
      • Targeting memory + resource leaks, use after free
      • AI: setup a day per month

  • [Pranith] What should be done about the cinder block?

Meeting date: 05/17/2017 (May 17th)

Meeting date: 04/19/2017 (Apr 19th)

Meeting date: 04/05/2017 (Apr 5th)

Meeting date: 03/08/2017 (Mar 8th)

  • Backlog consolidation as github issues
    • Further action pending
  • Maintainers v2.0
  • Demo hour
    • start with a 15 minute session at the end of the community meeting(s)
    • TODO: add a topic to the community meeting agenda, find someone to present
  • 3.11/3.12/4.0 calendar
    • Features, Testing focus for 3.11
  • Glusto tests and good build conversation
  • Replacement maintainer for Snapshots
    • AI: Vijay & Amar to suggest replacements on ML
  • Fedora 25, stay with glusterfs-3.9 (for 9 more months) or update to 3.10? (or is this a community meeting question?)
    • CentOS Storage SIG replaces 3.9 packages with 3.10 (in two update runs)

Meeting date: 02/22/2017 (Feb 22nd)

  • Github move post 3.10 (retire bugzilla)
    • Moving out of Bugzilla for bugs is not happening for 3.11
    • We will solidify movement of features, backlog, major fixes as github issues though for 3.11
    • [Shyam] to send updated workflow for this by end of the week
  • 3.10/3.11/4.0
    • 3.10 to release before end of Feb
    • Call out scope for 3.11 and 4.0 by end of Feb
    • Shyam would like to continue as the release owner for 3.11, to get github practice in place basically
      • Interested folks please let us know if you want to run it instead
    • Get github issues workflow ready by then (prerequisite?)
  • Backlog consolidation as github issues
    • Need increased momentum on this (Shyam)
    • Can we do this online, getting people together in locations to do this out? (Vijay)
      • +2
      • BLR volunteer: Kaushal (possibly next week)
      • Westford: Vijay/Shyam (next week)
      • Du/Shyam fill up backlog that was discussed for a series of components
      • Shyam to send the list evolved during meetings with Du and Nithya with others to elicit backlog for all components
      • Possibly improving regression testing is one major area
  • Focus area owners
    • Send a reminder, with notes on what it means to own a focus area, and how to drive it [Shyam]
  • FB patches and plans
    • Get things merged into master by 3.11
    • Help FB folks by actively moving patches from 3.8-fb to master and shepherding them
    • Call out for the same to hit devel with 3.11 announcement
  • Next release
    • Can we focus on test improvements exclusively for 3.11? (Kaushal)
      • +4
      • Glusto is kind of stuck, should we pick that up and focus on it? (Du)
        • +2
      • Get tests listed for 3.9 automated as a first step possibly (Pranith)

Meeting date: 02/08/2017 (Feb 8th)

  • Release 3.10 testing feedback
  • Release 3.10 documentation
  • Github move post 3.10 (retire bugzilla)
  • release 3.11 feature call out
  • release 4.0 feature call out
    • Is this STM/LTM? (Kaleb)
      • Even number release, and also first major release hence LTM is the proposal ATM
  • Focus area owners
  • Backlog consolidation as github issues

01/11/2017 (Jan 11)

Agenda: (Initiatives to check in at next meeting)

01/11/2017

Agenda:

Initiatives:

  • Backlog consolidation - Shyam
    • Gap analysis of what's missing for each component
    • Issues aren't appearing in github
    • Shyam to clean up project board (GEDI project mainly)
  • Test Automation - Raghavendra Talur & Pranith
    • Updates expected by end of the week
  • Performance - Shyam
  • Documentation / Website - Rajesh
    • AI: Amye to follow up on broken search with RTD
    • Amye will provide an update on website later
  • Technical Debt - Shyam, Du, Atin, Jeff
    • Resolving confusion around technical debt: keep asking questions
    • shyam and Raghavendra G will do a technical debt example for write-behind (and md-cache?)
  • Infra priorities going forward - Nigel

Forthcoming releases

<<< OLDER NOTES, Not cleaned up for HackMD or any MD style and leaving them be >>>

Replacing PublicPad

Amye to make an overview pad with better links 

link it on https://www.gluster.org/community/

Maintainers guidelines: https://docs.google.com/presentation/d/1N7Rtq4uiuDL1TLvX3wYdNQ3nID27PmVaszTCYWTHMOk/edit#slide=id.p -- New draft.

https://public.pad.fsfe.org/p/gluster-maintainer-lifecycle

01/04/2017 (Jan 4) Agenda:

Initiatives: 
    

Backlog consolidation - Shyam

Gap analysis of what's missing for each component

Issues aren't appearing in github 

Shyam to clean up project board (GEDI project mainly)

Test Automation - Raghavendra Talur & Pranith

Updates expected by end of the week 

Performance - Shyam 

outreachy, some small changes/feedback, mostly lack of responses/status updates

Documentation  - Rajesh

no rajesh, no others have an update

Technical Debt - Shyam, Du, Atin, Jeff 

Resolving confusion around technical debt: keep asking questions

shyam and Raghavendra G will do a technical debt example for write-behind (and md-cache?)

Facebook contributions

We need a tracker for things appearing on the fb branch and what is missing on master

developer experience is a priority for our work with them

Infra priorities going forward - Nigel

https://docs.google.com/document/d/1mvpopWl8ckX2pYhohfnWIhBWQUivV8-MWIK-dfByoyE/edit

Forthcoming releases

3.10

Multiplexing patch, needs a walkthrough to accelerate reviews

4.0 

on hold for Vijay

Replacing PublicPad

Amye to make an overview pad with better links 

link it on https://www.gluster.org/community/

Maintainers guidelines: https://docs.google.com/presentation/d/1N7Rtq4uiuDL1TLvX3wYdNQ3nID27PmVaszTCYWTHMOk/edit#slide=id.p -- New draft.

https://public.pad.fsfe.org/p/gluster-maintainer-lifecycle

AOB

12/21/2016 Agenda:

Initiatives: 
    

Backlog consolidation - Shyam

Test Automation - Raghavendra Talur & Pranith

Performance - Shyam 

Documentation  - Rajesh

Technical Debt - Shyam, Du, Atin, Jeff 

Adding items to Github project board 

Including Facebook patches

quota, rpc, dht, 

Forthcoming releases

3.10 and maintainer's actions on 3.10: Mid-January feature 'freeze' (not really but if they're not ready at that point, they can't get added in)

Brick multiplexing is on track, moving forward on actual multiplexing

Replacing PublicPad Maintainers guidelines: https://docs.google.com/presentation/d/1N7Rtq4uiuDL1TLvX3wYdNQ3nID27PmVaszTCYWTHMOk/edit#slide=id.p -- New draft. AOB

Next meeting 4 Jan to catch up on items missed due to lack of quorum

Next meeting on 14 December 2016 Moved to 21 December 2016 due to meeting conflicts

11/30/2016

Agenda:

Intiatives

Backlog consolidation - Shyam

http://www.gluster.org/pipermail/maintainers/2016-November/001726.html

GitHub project URL: 

https://github.com/gluster/glusterfs/milestone/1

https://github.com/gluster/glusterfs/projects/1

Test Automation - Raghavendra Talur & Pranith

Performance - Shyam 

perf regressions as a gate for 3.10 release is being acted on.

Documentation  - Rajesh

Tooling - right now in gitbook, looking into asciibinder

https://rajeshjoseph.gitbooks.io/test-guide/content/

Technical Debt - Shyam, Du, Atin, Jeff 

partially related to the backlog consolidation from Shyams 1st topic - GitHub project

Jeff: we need to consolidate the different backlog lists that are kept

AI/kshlm reach out to people to get updates sent to mailing 

Metrics for maintainers

How do we measure ourselves?

What are the quantitative aspects that we look forward from new maintainers?

Qualitative criterion - https://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/

Review the reviews 

http://people.redhat.com/ndevos/talks/Gluster-Summit-2015/Responsibilities_of_Gluster_Maintainers.pdf


Forthcoming releases

3.10

Shyam, Raghavendra Talur, Kaleb to be release maintainers

4.0

11/16/2016

Agenda:

Intiatives

Backlog consolidation - Shyam

http://www.gluster.org/pipermail/maintainers/2016-November/001726.html

Test Automation - Raghavendra Talur & Pranith

Adoption of glusto for 3.10

Performance - Shyam 

Aimed for weekly regression tests

Looking into beaker integration

Documentation  - Rajesh

Tooling - right now in gitbook, looking into asciibinder

https://rajeshjoseph.gitbooks.io/test-guide/content/

Technical Debt - Shyam, Du, Atin, Jeff 

partially related to the backlog consolidation from Shyams 1st topic - GitHub project

Jeff: we need to consolidate the different backlog lists that are kept

AI/kshlm reach out to people to get updates sent to mailing 

Metrics for maintainers

How do we measure ourselves?

What are the quantitative aspects that we look forward from new maintainers?

Qualitative criterion - https://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/

Review the reviews 


Forthcoming releases

3.9 (Aravinda/Pranith) - done, pending blog post + upgrade guide

steps needed for a release: http://gluster.readthedocs.org/en/latest/Contributors-Guide/GlusterFS-Release-process/

3.10

Shyam, Raghavendra Talur, Kaleb to be release maintainers

4.0

11/02/2016

Agenda:

Intiatives

Backlog consolidation - Shyam

AI/all: see email from Shyam, reply with feedback within a week

Test Automation - Raghavendra Talur & Pranith

glusto job on centos CI now available

Release tests to be automated first

Performance - Shyam 

Aimed for weekly regression tests

Looking into beaker integration

Documentation  - Rajesh

Tooling - right now in gitbook, looking into asciibinder

https://rajeshjoseph.gitbooks.io/test-guide/content/

Technical Debt - Shyam, Du, Atin, Jeff 

partially related to the backlog consolidation from Shyams 1st topic - GitHub project

Jeff: we need to consolidate the different backlog lists that are kept

AI/kshlm reach out to people to get updates sent to mailing list

Meetings with Facebook

Separate branch on upstream for landing patches

That would be a first step in getting all patches into mainline

Forthcoming releases

3.9 (Aravinda/Pranith)

3.10 I propose it should be 3.A

It was a joke, people

AI/all: come up with topics we want in 3.10 for the next meeting

FYI rpmdev-vercmp says 3.9 > 3.A  (IOW, No! No to it being 3.A)

and 3.9 < 3.10

4.0

Get ideas to AmyE for user survey!

10/18/2016

Agenda:

Intiatives

Backlog consolidation - Shyam

AI/all: see email from Shyam, reply with feedback within a week

Test Automation - Raghavendra Talur & Pranith

AI/rtalur: check with shweta/jonathan for upstreaming status of Glusto tests

AI/all: once Glusto examples are available, add more test cases for components

Performance - Shyam 

Facebook might be able to provide hardware (or time in their environment) for testing

gbench will most likely become the standard for performance testing

Documentation  - Rajesh

(Rajesh not attending, skipping)

Technical Debt - Shyam, Du, Atin, Jeff

partially related to the backlog consolidation from Shyams 1st topic - GitHub project

Jeff: we need to consolidate the different backlog lists that are kept

Release management - 

demanding (bi-)weely updates from leads (Samba, Ganesha, Glusto upstreaming, Container stuff, Kubernetes, Tiering, TGIF - must-fix-team, DHT, Replication)

pretty much what Kaushal sends out for GlusterD2 and Karthik did for WORM

failing community meeting attendance

maintainers should *really* try hard to attend, or send heads-up notes when unavailable

strongly encouraged for any Gluster contirbutor to attend, need to identify why this is not happening

Try out a simplified meeting next week without regular updates. Instead depend on regular updates sent to mailing lists.

AI/kshlm reach out to people to get updates sent to mailing list

Forthcoming releases

3.9

3.10 I propose it should be 3.A

AI/all: come up with topics we want in 3.10 for the next meeting

4.0

Generic comments:

Amye: make this meeting public, please. :D 

kshlm: +1

ndevos got kicked out of bluejeans, reconnecting fails... and I'm back!

09/14/2016 Agenda

  1. Review inputs

    While we were discussing this yesterday, Github announced something similar to what we need

    http://venturebeat.com/2016/09/14/github-launches-a-trello-competitor-pull-request-reviews-redesigned-profile-pages/

    Here is a demo I created: https://github.com/raghavendra-talur/vagrant-cluster-creator/projects/1#card-49668

    1. what we get:

    2. Existing issues can be added as cards easily, and they are linked

    3. You can create corresponding issue for any card easily

    4. You can have multiple project boards, say, one per xlator or component.

    5. using card urls for linking from main project board to component board.

    6. What is not possible:

    7. You cannot link existing card to existing issue. You will have to delete one and create it linked with another.

    8. comment on cards

    9. card labels

    10. assignee on cards(assignee on issue linked to card is possible)

    11. Moving cards across projects

  2. Managing backlog going forward

  3. Planning and Prioritization for future releases

    4.0

    3.9

    3.10

  4. Initiatives & Owners

    Testing

    Raghavendra Talur

    Pranith Kumar K

    Performance

    Shyam

    <+1 Looking for a partner, would help>

    Stability / Technical Debt

    Shyam, Du, Atin, Jeff

    Infrastructure

    AI: follow up with Nigel

    Process changes

    Documentation

    Rajesh - Humble?

    ...

  5. Anything else

Add a custom footer
Add a custom sidebar
Clone this wiki locally