[Gluster-users] [Gluster-devel] Meeting minutes for the Gluster community meeting held on 25-05-2021
Saju Mohammed Noohu
sajmoham at redhat.com
Wed May 26 08:56:35 UTC 2021
On Tue, May 25, 2021 at 6:51 PM sankarshan <sankarshan at kadalu.io> wrote:
> Ayush - thank you for hosting what is your first Gluster community
> meeting! It was an excellent effort at keeping the conversation moving
> Some additional comments in-line.
> On Tue, 25 May 2021 at 17:52, Ayush Ujjwal <aujjwal at redhat.com> wrote:
> > # Gluster Community Meeting - 25/05/2021
> > * Project metrics:
> > | Metrics | Value |
> > | ------------------------- | -------- |
> > |[Coverity](https://scan.coverity.com/projects/gluster-glusterfs) |
> 38 |
> > |[Clang Scan](https://build.gluster.org/job/clang-scan/lastBuild/) |
> 89 |
> > |[Test coverage](
> 70.9 |
> > |[Gluster User Queries in last 14 days](
> | 27 |
> > |[Total Github issues](https://github.com/gluster/glusterfs/issues)
> | 315 |
> As brought up at the meeting - it might be useful to discuss the trend
> of these values and from there deduce if these are in the right
> direction. The values in isolation do not communicate enough data to
> determine whether there are opportunities to improve. At a certain
> point in time in early 2020 there was intense focus on test coverage.
> I am not sure if that has resulted in actual better coverage or just
> spreading butter on toast.
Please follow the gluster-devel mailing list, there is a email sent out
With subject: "Gluster Code Metrics Weekly Report", which gives weekly
and a trend graph and links to the respective jobs.
On the test coverage: Yes we need more participation from community.
> > * Any release updates?
> > * None
> > * Blocker issues across the project?
> > * It looks like the lock-recovery changes introduced with
> https://review.gluster.org/#/c/glusterfs/+/22712/ has issues. We already
> fixed https://github.com/gluster/glusterfs/pull/2456 and
> https://github.com/gluster/glusterfs/issues/2337 but looks like the code
> is buggy. Need someone to take a look at the difference between posix-locks
> and client xlators in how the locks are maintained to fix the issue
> As a project it is necessary to do right by our community - this means
> that the impact of the issue and remedy/workaround should be
> immediately shared widely enough to ensure that this is not missed.
> Since the issues are tagged 'blocker' I am guessing that these meet
> the somewhat established criteria of a blocker issue and would need an
> enhanced level of attention. Have the issues been triaged and
> developers assigned?
The above doesnt look to be a blocker issue as this happens on particular
locking pattern. Discussed and confirmed this with Pranit yesterday. The
fix for this will go in the next minor releases happening in June. We do
highlight issues in the release notes; this is not a showstopper one.
> > * Notable thread form mailing list
> > * Not exactly from mailing list. Slack user pinged me and asked me
> if it is possible to let the users know of any known issues in the latest
> releases so that they can make a decision about which version to use. For
> example: 9.0 and 9.1 had protocol issue.
> > * Along the same lines, I wanted to ask one more question. Should we
> release beta-releases for major releases so that we get feedback about any
> issues that happen in their particular environment to address the issues
> even before the stable releases are made?
> I've offered to look at the criteria which defines a 'beta' and check
> how it aligns with a release schedule. The history of 'beta' releases
> of storage software (as compared to say a browser) is that we have
> often received no uptake. There are many reasons for this - but one
> key aspect is that it is additional work being asked from the
> community. If the 'beta' is reasonably well described perhaps the
> accrued value from this testing cycle would be better understood.
The key aspect statement: "additional work being asked from the
community" itself is worrying. The community should help and serve each
As community, we expect more participation.
As you know its practically not possible to test all
That is why more regression tests will make sense here.
> Community Meeting Calendar:
> Schedule -
> Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
> Bridge: https://meet.google.com/cpu-eiue-hvk
> Gluster-users mailing list
> Gluster-users at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users