[FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

Michael Niedermayer michael at niedermayer.cc
Fri Feb 9 00:43:20 EET 2018


On Thu, Feb 08, 2018 at 06:21:06PM +0100, wm4 wrote:
> On Thu, 8 Feb 2018 12:34:07 -0300
> James Almer <jamrial at gmail.com> wrote:
> 
> > On 2/8/2018 7:25 AM, Rostislav Pehlivanov wrote:
> > > On 8 February 2018 at 10:06, Nicolas George <george at nsup.org> wrote:
> > >   
> > >> Michael Niedermayer (2018-02-08):  
> > >>> +1  
> > >>
> > >> I agree too.
> > >>
> > >> And maybe, since we are reverting something, revert the whole series.
> > >>
> > >> Regards,
> > >>
> > >> --
> > >>   Nicolas George
> > >>
> > >> _______________________________________________
> > >> ffmpeg-devel mailing list
> > >> ffmpeg-devel at ffmpeg.org
> > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >>
> > >>  
> > > 
> > > -1, I object to reverting anything.
> > > We should fix what we have right now. The API looks good too except some
> > > people here feel like they haven't bikeshedded enough and want to cause
> > > even more chaos.
> > > One bad commit and you all go screaming revert with your pitchforks instead
> > > of trying to fix it.  
> > 
> > A set of seven patches was pushed before any of them got a full review
> > or even an ok, which unsurprisingly introduced a plethora of issues, and
> > all while there were discussions going about implementing the API in a
> > different way by more than one developer.
> > I do not, under any circumstance, support this strategy of pushing
> > unfinished things and then argue that since it's already committed it
> > can't be touched. I have no idea how you or anyone could support this
> > kind of thing.
> > 
> > The entire set should be reverted if only to make it clear that this is
> > not how development should work, yet everyone so far, including myself,
> > has suggested to only revert the one non-API commit that badly broke a
> > lot of things, then work on top of the already introduced API to
> > effectively finalize it, and then fix and reapply any implementation bits.
> 

> The author spent weeks on fixing all the issues, updating the patch set
> multiple times, and so on. In the end, he didn't get much helpful
> reviews, but tons of bikeshedding that was unproductive as hell. Also
> it seems he formally didn't violate any rules, because he fixed the
> issues and waited long enough.

Theres no need to polarize the discussion any further.
neither attacking anyone nor glorifying the author of a patchset
with a inprecisse statement where a correction would likely insult the author.
iam sure he is already stressed from having pushed a patchset that introduced
some issues.

We are one team, if WE have a bug in the code we should fix it or revert the
patch causing it. If a issue is trivial to fix then fixing is better. If it
is complex and one works under pressure its likely better to revert so as not
to introduce more mistakes and have a clean known to work basis ...

Thanks

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180208/fda9a683/attachment.sig>


More information about the ffmpeg-devel mailing list