[CentOS-devel] Status of CentOS SIGs

Sat Jan 16 17:00:00 UTC 2021
Strahil Nikolov <hunter86_bg at yahoo.com>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210116/8f37d304/attachment-0005.html>