[FFmpeg-devel] core infrastructure badge for FFmpeg

[Michael Niedermayer]

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")


> This should provide sufficient time.
> Really, all it requires is changing the "informal/soft constraint" to a "hard" constraint,
> and accordingly noted in the dev docs.
> 
> I treated the "must" here as a hard constraint.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160706/672d74cb/attachment.sig>