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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Shankarsan,

Replies inline.

Thanks
Saju


On Tue, May 25, 2021 at 6:51 PM sankarshan <sankarshan@xxxxxxxxx> wrote:
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@xxxxxxxxxx> 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.
 
Please follow the gluster-devel mailing list, there is a email sent out every Monday
With subject: "Gluster Code Metrics Weekly Report", which gives weekly values 
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 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?
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 other.
As community, we expect more participation.
As you know its practically not possible to test all scenarios/usecases/setups.
That is why more regression tests will make sense here.
 
Thanks
Saju




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@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users

-------

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-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel


[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux