[FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
wm4
nfxjfg at googlemail.com
Thu Feb 8 19:21:06 EET 2018
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.
And now that some breakages occurred (which is not that surprising
since the patch changes so much), most mails on this topic are STILL
unhelpful bikeshedding.
Keeping patches in bikeshed hell while not giving good reviews (like
Michael just posting a specific command line and then saying "it broke"
while not saying anything actually helpful, or certain other devs who
came up with almost equivalent ideas how the components should be
iterated but which they have unusually strong opinions about), is a
good way to make developers leave and to make the mood of the project
worse.
Just saying.
More information about the ffmpeg-devel
mailing list