[FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

Michael Niedermayer michael at niedermayer.cc
Thu Nov 30 04:51:10 EET 2017


On Wed, Nov 29, 2017 at 01:06:06PM -0800, Jim DeLaHunt wrote:
> On 2017-11-29 06:53, Compn wrote:
> 
> >[...]
> >>Also, someone once observed that common sense is not very common. :-)
> >sure, but please remember the DOCS are already quite verbose, and
> >brevity is the soul of wit. so if you can say more with less verbiage
> >that would be great.
> >[...]
> >Also please note that most ffmpeg developers and patch authors are from
> >around the world , and english may not be their native language.
> I'd be happy to work on better wording. I think the obstacle is more
> fundamental: there isn't agreement on what to say, or a consensus
> that it should be said at all.
> 
> >
> >>I find it interesting that bug fixes and enhancements to the source code
> >>of ffmpeg are approved so much more easily than this patch's bug fixes
> >>and enhancements to the text of ffmpeg.org. This is not a smooth
> >>documentation process.
> >haha! well let me please explain to you what situation you have gotten
> >yourself stuck into! :)
> >
> >the development docs that you want to patch are actually the ffmpeg
> >project's written rules and policy that governs the whole shebang.
> >
> >so these are the rules that all devs must agree to within the project.
> >sure, we bicker about the rules and not everyone follows every rule,
> >and we have many unwritten rules that we also abide by. which also
> >causes great strife sometimes when someone thinks a rule is official or
> >not... look i didnt say it was a good system, it is what we have
> >evolved into over the years.
> >
> >the point is that changes to this specific part of the documentation
> >affects all devs, not just new contributors. so we are more interested
> >to changes of this document. especially large changes all in one patch.
> >
> >what your v1 patch has unintentionally done is to change our long
> >standing ffmpeg policy about patch submission and review. i know this
> >was not your intention, but you have picked one of the core parts of the
> >project to modify on your first attempt. :)
> 
> What this says to me is that the problems I observe in
> ffmpeg.org/developer.html go deeper than wording.
> 
> There are architectural problems: this one page is supposed to serve
> as both the reference for the project's rules and as a tutorial for
> new contributors. The requirements for these two purposes differ.
> 

> There are governance problems: rules exist for important parts of
> the project, but they are not in writing. Exhibit 1 is that the
> ffmpeg-devel list is central to this project, but there is presently
> zero description of it in this web page. Exhibit 2 is that the
> actual practice of the ffmpeg-cvslog list by several senior
> developers clearly differs from the description of it in this page.

the cvslog list was in the past used in a way thats more
similar to the text, practice changed, probably primarly as the tools
changed from cvs to svn to git.
git has a local, efficient and fast log where one can see all changes.
the prior version control systems lacked that, this may have been
te reason cvslog was more used and important.

The text maybe doesn fully reflect this but it is wrong towards a
arguably benefitial side. That is when more people look & review changes
which are pushed, that is a good thing.

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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/20171130/f379f405/attachment.sig>


More information about the ffmpeg-devel mailing list