[FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

05.07.2016, 18:03, "Michael Niedermayer" <michael at niedermayer.cc>:
>   On Tue, Jul 05, 2016 at 05:45:19PM -0400, Ganesh Ajjanagadde wrote:
>>    05.07.2016, 17:29, "Michael Niedermayer" <michael at niedermayer.cc>:
>>    > On Mon, Jul 04, 2016 at 09:15:27PM -0400, Ganesh Ajjanagadde wrote:
>>    >>  04.07.2016, 15:55, "Ronald S. Bultje" <rsbultje at gmail.com>:
>>    >>  >  Hi,
>>    >>  >
>>    >>  >  On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>>    >>  >
>>    >>  >>   04.07.2016, 15:36, "Ronald S. Bultje" <rsbultje at gmail.com>:
>>    >>  >>   > Hi,
>>    >>  >>   >
>>    >>  >>   > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde <gajjanag at mit.edu>
>>    >>  >>   wrote:
>>    >>  >>   >
>>    >>  >>   >> 04.07.2016, 10:33, "Clément Bœsch" <u at pkh.me>:
>>    >>  >>   >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde <gajjanag at mit.edu>
>>    >>  >>   >> wrote:
>>    >>  >>   >> >> Hi,
>>    >>  >>   >> >>
>>    >>  >>   >> >> https://bestpractices.coreinfrastructure.org/.
>>    >>  >>   >> >>
>>    >>  >>   >> >> Thoughts on getting this done for FFmpeg?
>>    >>  >>   >> >
>>    >>  >>   >> > Any thing we need to adjust in the project? I don't see much things
>>    >>  >>   to
>>    >>  >>   >> > change by looking at
>>    >>  >>   >> https://bestpractices.coreinfrastructure.org/projects/1
>>    >>  >>   >>
>>    >>  >>   >> I could not either.
>>    >>  >>   >> It was something I noticed a week back, judged low-hanging and of some
>>    >>  >>   >> benefit to the project.
>>    >>  >>   >> I thus am willing to do it, provided there are no objections.
>>    >>  >>   >
>>    >>  >>   > I think if any changes are necessary to the website or documentation or
>>    >>  >>   > code, these would simply go through the relevant review process, right?
>>    >>  >>   Or
>>    >>  >>   > am I missing something?
>>    >>  >>
>>    >>  >>   True. At the moment, it seems like the relevant forms can be filled in
>>    >>  >>   directly from existing information,
>>    >>  >>   and no changes are necessary.
>>    >>  >>
>>    >>  >>   I can send a screenshot of the filled out form before submitting if people
>>    >>  >>   want.
>>    >>  >
>>    >>  >  Oh I see, I misunderstood. I personally don't have objections to that.
>>    >>
>>    >>  Turns out that the first few pages are easy to fill and we already achieve them.
>>    >>  The last few are much harder, and FFmpeg does not currently meet all of them.
>>    >>
>>    >>  Here is the progress so far: https://bestpractices.coreinfrastructure.org/projects/235.
>>    >>
>>    >>  I have filled them to the best of my ability.
>>    >>  Here is a summary of where we fail to meet the criteria,
>>    >>  and some suggestions for what we could do.
>>    >>
>>    >>  The "MUST" constraints are the ones where FFmpeg needs to improve,
>>    >>  assuming the project wishes to get to 100%.
>>    >
>>    >>  1. The project MUST have evidence that such tests are being added in the most recent major changes to the project.
>>    >>  Suggestion: enforce tests for all new filters, muxers, etc. At least 6 months back, this was not enforced for lavfi.
>>    >
>>    > The details for this reads "Major functionality would typically be mentioned in the ChangeLog. (Perfection is not required, merely evidence that tests are typically being added in practice.) "
>>    >
>>    > diffstat between 3.0 and 3.1 of make fatelist shows
>>    > fatelist-3.1 | 281 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>>    >  1 file changed, 275 insertions(+), 6 deletions(-)
>>    >
>>    > so there are 269 more tests in 3.1 than 3.0
>>    >
>>    > limiting this to filters shows
>>    > grep filter fatelist-3.0> fatelist-3.0-filter
>>    > grep filter fatelist-3.1> fatelist-3.1-filter
>>    > diff -u fatelist-3.0-filter fatelist-3.1-filter | diffstat
>>    >  fatelist-3.1-filter | 25 +++++++++++++++++++++++++
>>    >  1 file changed, 25 insertions(+)
>>    >
>>    > we have 15 filters in the 3.0->3.1 changelog if i didnt miscount
>>    >
>>    > so i would say we are maybe a bit behind with adding tests but they
>>    > do get typically added eventually even for libavfilter.
>>    > No question, it would be better if tests would be added quicker ...
>>
>>    I do not doubt this, but at the moment we do not enforce it.
>
>>    Do you see any trouble in enforcing this requirement from major release to next major release?
>
>   thats more a question for everyone / the community than me (in case
>   this was meant as singular "you")

I was referring to the release manager(s).

Is it customary to vote on these things,
or let it pass through the standard informal review process?

I have updated the info based on the messages in this thread.
The current entries may be viewed at:
https://bestpractices.coreinfrastructure.org/projects/235.

I believe the above is the main blocker for getting to 100%.

Thanks.

[...]