<div dir="ltr"><div>To add to what Nicolas said, the "good, bad, ugly" joke has also changed meaning over time. For instance, "bad" plugins used to mean:</div><div><br></div><div>> 
GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par compared to
the rest.  They might be close to being good quality, but they're missing
something - be it a good code review, some documentation, a set of tests, a
real live maintainer, or some actual wide use. <br></div><div><br></div><div>But in reality, most of the code in the -bad module is good quality since all code merged into any gstreamer module gets code review on GitLab, basically every plugin has documentation (at least API docs), and since everything new goes into -bad, all new code in -bad is actively maintained.</div><div><br></div><div>The vast majority of the time, code that would be considered "excellent quality" by almost anyone continues to be in -bad because:</div><div><br></div><div>1. The API is unstable because the underlying tech is evolving, or we are understanding people's use-cases better. In an open-source project with dozens or hundreds of stakeholders, it takes time to get to an understanding of how everyone uses things.</div><div>2. No one has felt the need to move it over yet even though the code is ready to be moved, because it requires work that has little benefit and in fact breaks file-level git history (git blame).</div><div><br></div><div>There is plenty of code in -bad that has been used in production for years at thousands of companies around the world but is still in -bad because no one has bothered to move it. I have plenty of examples of this: webrtc, wasapi, wasapi2, nvcodec, mediafoundation, dtls, opus, openh264, srtp, sctp, wayland, vulkan, inter, mpegtsmux, and more.<br></div><div><br></div><div>On the flip side, there is no mechanism for moving plugins from "good" to "bad", so there is code that is bitrotting because there isn't a maintainer for it anymore, or the underlying APIs are deprecated (f.ex., directsound), or the library that the plugin wraps is dead / outdated / obsolete, or there were changes elsewhere in gstreamer that weren't incorporated into this plugin and no one noticed.</div><div><br></div><div>On top of all this, some plugins are in the "-base" module, which doesn't even fit into the "good, bad, ugly" joke. We don't even put libraries in "good", they go from "bad" to "base". Some libraries go straight into the core module "gstreamer" such as GstPromise if they count as "core API" that will be used by all modules.<br></div><div><br></div><div>To summarize:</div><div><br></div><div>1. The naming scheme has no relation to the meanings of the words used in the categories, and the joke anyway meant "bad as in "bad person" not "bad quality"</div><div>2. Directory-level categorization has unwanted side-effects<br></div><div>3. It is difficult to gauge the "code quality" of plugins, for many reasons, so even labels might not work</div><div>4. It was a dumb idea to call our own code "bad", even dumber to keep using that term when it is not even useful<br></div><div>5. We should probably get rid of this categorization for plugins and libraries, maybe just a "staging" area, a "deprecated" area, and a "normal" area</div><div>6. This topic is prime bikeshedding material, so don't count on it ever getting done</div><div>7. Deriving "security" implications from this categorization is a futile exercise, might as well read tea-leaves<br></div><div><br></div><div>Please feel free to refer your security team to this email thread as supporting evidence. If they have questions, it's best to ask on this same mailing list or on our IRC / Matrix channel #gstreamer on OFTC. The gstreamer website has outdated information regarding our security practices too, since the website usually has outdated information (it needs a rewrite).<br></div><div><br></div><div>Cheers,</div><div>Nirbheek<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 11, 2022 at 9:30 AM Nicolas Dufresne via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 10 juin 2022, 17 h 17, pranav sharma <<a href="mailto:prsmsft@gmail.com" target="_blank">prsmsft@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks for your response. Someone on this list asked why it matters if the plugin is in bad or good state. It's a matter of perception. Our internal production teams have a very high bar for quality and security. No plugins that are marked as "bad" will be acceptable. If Microsoft is going to checkin a plugin it'll be maintained by our team as it's going to be used by our internal partner teams in production; we just don't have any other option.<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Somehow though your team will have to read the documentation to translate this good, bad and the ugly joke into what this is really is.</div><div dir="auto"><br></div><div dir="auto">The bad repository is a staging area. We don't commit to a stable API there yet. That includes we can remove or change element properties, change API if we are making a library. It has nothing to do with code quality, code there is getting the same attention as any other code, and a security report there will have the same severity. Remember, we do have crucial bit of software that seems to stay forever in there, notably our bitstream parsers. Without these, you cannot do much video playback in GStreamer. It really hard to commit to a final and stable API for such a thing.</div><div dir="auto"><br></div><div dir="auto">No matter how good, great, high standard your team is, you will have to land your work there first. Considering the learning curve, I believe in order to achieve this high standard you will need reviews, comment feedback from experienced GStreamer developers.  Challenging your team design I the public space and getting feedback from third is definately the right way to do Open Source and grow community around your code. GStreamer maintainers are no robots, if you send large chunk of code at us without getting us involved, you may endup waiting very long before someone can do the extra work, and your team might have moved on when we start raising issues and asking for changes to allow merging your code.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Nicolas</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 10, 2022 at 8:19 AM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" rel="noreferrer" target="_blank">nicolas@ndufresne.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le vendredi 10 juin 2022 à 11:52 +0100, Tim-Philipp Müller via gstreamer-devel a<br>
écrit :<br>
> There are some checklist items here<br>
> <br>
> <a href="https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/docs/random/moving-plugins" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/docs/random/moving-plugins</a><br>
> <br>
> but it's not really a superwell defined process. The technical / code style<br>
> bits are usually easy, but then there's also a subjective "does it seem ready<br>
> and in good shape" bit to it, and a question or whether the plugin API is good<br>
> and will likely stand the test of time. Does the plugin seem actively<br>
> used/maintained? Are multiple GStreamer developers familiar with it and can<br>
> help maintain it?  Is there a group of external contributors who is actively<br>
> using and contributing or maintaining it? Are people using it successfully,<br>
> what issues, warts, problems have they run into that should perhaps be fixed<br>
> before a move, etc.<br>
> <br>
> On the upside there's probably no issue with licensing/patents here on the<br>
> plugin side.<br>
<br>
<br>
Adding my two cents, if you are to run this on Windows, you likely want to add<br>
any missing D3D11/12 support for zero-copy, and the lib for that is only<br>
available in -bad as its API is not yet considered stable. So see that as a good<br>
thing, it gives you maximum flexibility to get things working very smoothly.<br>
<br>
Nicolas<br>
</blockquote></div>
</blockquote></div></div></div>
</blockquote></div>