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