New plugin for ONNXRuntime

[Nicolas Dufresne]

Le ven. 10 juin 2022, 17 h 17, pranav sharma <prsmsft at gmail.com> a écrit :

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

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.

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.

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.

Regards,
Nicolas



> On Fri, Jun 10, 2022 at 8:19 AM Nicolas Dufresne <nicolas at ndufresne.ca>
> wrote:
>
>> Le vendredi 10 juin 2022 à 11:52 +0100, Tim-Philipp Müller via
>> gstreamer-devel a
>> écrit :
>> > There are some checklist items here
>> >
>> >
>> https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/docs/random/moving-plugins
>> >
>> > but it's not really a superwell defined process. The technical / code
>> style
>> > bits are usually easy, but then there's also a subjective "does it seem
>> ready
>> > and in good shape" bit to it, and a question or whether the plugin API
>> is good
>> > and will likely stand the test of time. Does the plugin seem actively
>> > used/maintained? Are multiple GStreamer developers familiar with it and
>> can
>> > help maintain it?  Is there a group of external contributors who is
>> actively
>> > using and contributing or maintaining it? Are people using it
>> successfully,
>> > what issues, warts, problems have they run into that should perhaps be
>> fixed
>> > before a move, etc.
>> >
>> > On the upside there's probably no issue with licensing/patents here on
>> the
>> > plugin side.
>>
>>
>> Adding my two cents, if you are to run this on Windows, you likely want
>> to add
>> any missing D3D11/12 support for zero-copy, and the lib for that is only
>> available in -bad as its API is not yet considered stable. So see that as
>> a good
>> thing, it gives you maximum flexibility to get things working very
>> smoothly.
>>
>> Nicolas
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220610/ae7fb1d4/attachment.htm>