[FFmpeg-devel] [PATCH] thp: set duration

Michael Niedermayer michaelni at gmx.at
Tue Dec 18 20:37:09 CET 2012


On Tue, Dec 18, 2012 at 05:40:08PM +0000, Paul B Mahol wrote:
> On 12/17/12, Derek Buitenhuis <derek.buitenhuis at gmail.com> wrote:
> > On 17/12/2012 3:34 PM, Paul B Mahol wrote:
> >>>> applied
> >>>
> >>> Excuse me?
> >>>
> >>> You have pushed it whilst completely ignoring my reviews. You have not
> >>> even provided an explanation. This is incredibly rude and
> >>> unprofessional.
> >>>
> >>> I don't think this sort of behavior is acceptable in a collaborative
> >>> environment.
> >>>
> >>> Perhaps you can expand on why?
> >>
> >> Many demuxers use number of frames in stream as stream duration.
> >>
> >> If you do not like current state post patch that address this by using
> >> nb_frames to set duration (similar how it is done for bitrate). This
> >> would also factorize some code.
> >
> > It's all well and fine that the patch was technically correct (for reasons
> > other
> > than you listed here, actually), but that does not make it OK to disregard
> > others'
> > reviews entirely and apply things without explanation or even the courtesy
> > to nte
> > why. That is -extremely- rude and unprofessional, and very counterproductive
> > in
> > creating a collaborative environment for development.
> 
> Counterproductive and time consuming are reviews and rants as
> demonstrated in this and
> another thread.
> 
> I ignore and will ignore such demonstration of bad faith.

ehm, moment, noone can ignore reviews when working with a shared
repository. That leads to problems for everyone involved.

Let me quickly summarize what has happened from my point of view and
from how i remember without re reading things.

There was a patch that was technically good, but had a terse commit
message and not everyone understood immedeatly how the code works. So
a better commit message was suggested and some discussion started
with the intent to confirm that its all ok, correct and optimal.
But before that reached a conclusion the patch with the terse commit
message was applied.

I agree with you that technically its no big thing in this case as
what was commited is acceptable. But i also agree with derek that this
is quite offensive and problematic in a collaborative environment.

Thus what i would suggest is that either or all of:
A. People have their own git repositories (iam advocating this since a
   long time as many know) and as its each owners own repository then
   they can do anything in that, that they want. No need to wait for a
   review or bother about other people, though it makes alot of sense
   to do listen to others this is every owners free choice.
   And i can then merge these repositories into master, in which case
   people can flame me if i do something silly.

B. Each part of ffmpeg should have a maintainer, and that person has
   the final say on what is ok and what not. He of course should
   listen to reviews and comments and consider them but a maintainer
   can decide that a review has gone way of track and is just
   filibustering and bikesheding and could then as a last resort ignore
   it and apply the patch.

C. In absence of developers using their own git repos and in absence
   of a maintainer (like in the thp case). Reviews should not be
   ignored.

Thanks

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121218/872a66bb/attachment.asc>


More information about the ffmpeg-devel mailing list