<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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.</div></div></div></blockquote><div>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.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>When people actually start attending then I'd be willing to consider having more.</div></div></div></blockquote><div>I never ment "more", but more productive. Even if it's just "no issues are observed".</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">I saw that multiple components in Storage SIG fail when we<br>
add SELINUX to the equasion.<br></blockquote><div><br></div><div>Where are the bug reports or github issues?</div></div></div></blockquote><div>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.</div><div>If I had a clue which component is the "guilty one"... it would be far easier.</div><div>One example (should be solved in EL 8.3):
CentOS 8.2, Gluster v8.3 + Highly Available NFS Ganesha ontop of a Gluster Cluster.</div><div>When the system was fenced - it never came back. Which is guilty -> Gluster, NFS Ganesha, or EL ?</div><div> </div><div>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.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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.</div></div></div><div dir="ltr"><div class="gmail_quote"><div>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.</div></div></div></blockquote><div>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.</div><div><br></div><div>Best Regards,</div><div>Strahil Nikolov</div></body></html>