<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">prsmsft@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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" target="_blank" rel="noreferrer">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>