srsly? You want more meetings? For three months in a row last year Niels and I sat around on #centos-meeting at the scheduled time waiting to see if anyone else was going to show up. Each time, after about 15 minutes we called it quits.
As it was mentioned , it could be an e-mail based and that could solve the problem people not able to attend. After all people have jobs to do ... and not everybody is on the software development end.
When people actually start attending then I'd be willing to consider having more.
I never ment "more", but more productive. Even if it's just "no issues are observed".
I saw that multiple components in Storage SIG fail when we
add SELINUX to the equasion.
Where are the bug reports or github issues?
First of all it's so hard to identify which product should be addressed first. I was trying with Gluster devel , yet it's not optimal - nothing goes on, no followup , nothing.
If I had a clue which component is the "guilty one"... it would be far easier.
One example (should be solved in EL 8.3):
CentOS 8.2, Gluster v8.3 + Highly Available NFS Ganesha ontop of a Gluster Cluster.
When the system was fenced - it never came back. Which is guilty -> Gluster, NFS Ganesha, or EL ?
That's just a simple case where you and the rest of the SIG helped, but it was so hard to get that resolved. Such SIG meetings would help.
Although honestly, if you find a bug (e.g. a crash, an AVC denial, etc.) please report it directly to the upstream project. Unless it's a bug that's directly related to the actual packaging... I've frankly got better things to do than be a proxy for bugzillas and github issues.
The packages I'm involved with use an rpm .spec file that is 99% identical to the upstream project's .spec file, so even if there's a bug in the packaging, odds are it should get reported upstream (first) anyway.
About the proxying stuff... that's not intended or wished - but sadly sometimes it happens. After all , the goal is to make the components in this SIG better.
Best Regards,
Strahil Nikolov