> > Signed-off-by: Nicolas George <geo...@nsup.org> > > --- > > doc/developer.texi | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > Rather than repeat myself, I'll refer to my previous mails: > > * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html > * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238743.html > > I utterly and absolutely think no good will come from such a policy. It's > divisive, exclusionary, inflamatory, witch-hunt-y, and privacy invading, > among other things. > > I'm speechless. Words cannot describe how terrible I think such a policy is > for current and future contributors, and I am of the opinion that adopting > such a policy would see any work sent to FFmpeg by anyone involved in a > company, which I may add, is a lot, utterly dry up. > > I've not much more to say on the matter, and I will not engage in flame > wars after. > > - Derek > > (P.S. Just how do you intend to enforce this? How do you prove/disprove > someone > has been paid in some form, directly, or indiectly? Do you just accuse them > on > the list?) > > (P.P.S. I am aware my opinions hold little clout here nowadays, so take my > response > as you will.) > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
My official contributions to ffmpeg are small and as such there isn't much value in my saying "I agree as well". By now I've got a much longer list of changes that I haven't submitted back as patches to ffmpeg than those where I did. This happened for various reasons none of which to blame ffmpeg for. Many others are doing the same. That leads to fragmentation of the code base of course. Fragmentation is not a bad thing per se - many changes are not suitable for general inclusion. But sometimes it can be even just small things keeping an individual developer from submitting patches back when he's got the option to go with his own "ffmpeg+custom" code base. That kind of fragmentation is bad of course, when the common code base could have benefited from a change. Establishing a "transparency requirement" as described, would set up an additional - for some even huge - impediment for contributing back their work. So, while my consent is surely irrelevant (per my own conviction), I really wonder if such a decision would be good for the project. softworkz _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
