[FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches

[Anton Khirnov]

Quoting Soft Works (2022-11-14 10:35:40)
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Anton Khirnov
> > Sent: Monday, November 14, 2022 10:13 AM
> > To: ffmpeg-devel at ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the
> > argument for submitting patches
> > 
> > Stop talking about commercial programs, since this applies to any
> > downstream user.
> > ---
> >  doc/developer.texi | 20 +++++++++++++++-----
> >  1 file changed, 15 insertions(+), 5 deletions(-)
> > 
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index 5cf3b19ee0..2f0d2b7daa 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -24,11 +24,21 @@ generated from the headers
> >  the examples under @file{doc/examples}
> >  @end itemize
> > 
> > -You can use the FFmpeg libraries in your commercial program, but you
> > -are encouraged to @emph{publish any patch you make}. In this case
> > the
> > -best way to proceed is to send your patches to the ffmpeg-devel
> > -mailing list following the guidelines illustrated in the remainder
> > of
> > -this document.
> > +If you modify FFmpeg code for your own use case, you are highly
> > encouraged to
> > + at emph{submit your changes back to us}, using this document as a
> > guide. There are
> > +both pragmatic and ideological reasons to do so:
> > + at itemize @bullet
> > + at item
> > +Maintaining external changes to keep up with upstream development is
> > +time-consuming and error-prone. With your code in the main tree, it
> > will be
> > +maintained by FFmpeg developers.
> 
> You should mention that sometimes it's not really worth to take the effort,
> because waiting for reviews and permanent rebasing and re-submitting,
> explaining, defending, getting insulted or ignored and whatsoever,
> might end up taking much more time than just to keep and maintain your 
> changes privately. Eventually you might regret that you have even
> started going that way.

Sorry, but you problems are entirely self-inflicted. You have been told
what changes need to happen right from the beginning, repeatedly, and by
several developers independently. Instead of implementing them you chose
to compose ever-more-elaborate explanations and justifications that, as
far as I can tell, boil down to "doing things properly is too much
work". Seems to me that actually doing this work would take less time
than you have already spent arguing.

-- 
Anton Khirnov