05.07.2016, 18:03, "Michael Niedermayer" <mich...@niedermayer.cc>: > On Tue, Jul 05, 2016 at 05:45:19PM -0400, Ganesh Ajjanagadde wrote: >> 05.07.2016, 17:29, "Michael Niedermayer" <mich...@niedermayer.cc>: >> > On Mon, Jul 04, 2016 at 09:15:27PM -0400, Ganesh Ajjanagadde wrote: >> >> 04.07.2016, 15:55, "Ronald S. Bultje" <rsbul...@gmail.com>: >> >> > Hi, >> >> > >> >> > On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde >> <gajja...@mit.edu> wrote: >> >> > >> >> >> 04.07.2016, 15:36, "Ronald S. Bultje" <rsbul...@gmail.com>: >> >> >> > Hi, >> >> >> > >> >> >> > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde >> <gajja...@mit.edu> >> >> >> wrote: >> >> >> > >> >> >> >> 04.07.2016, 10:33, "Clément Bœsch" <u...@pkh.me>: >> >> >> >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde >> <gajja...@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. [...] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
