[Gluster-users] [Gluster-devel] Meeting minutes for the Gluster community meeting held on 25-05-2021

[sankarshan]

Ayush - thank you for hosting what is your first Gluster community
meeting! It was an excellent effort at keeping the conversation moving
along.

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

[snip]

> * 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](https://build.gluster.org/job/line-coverage/lastCompletedBuild/Line_20Coverage_20Report/)|    70.9 |
> |[Gluster User Queries in last 14 days](https://lists.gluster.org/pipermail/gluster-users/2021-May/thread.html#start)        |     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.

>
> * 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 completely.
>

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?

>
> * 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.