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

[Paul B Mahol]

On 12/18/12, Michael Niedermayer <michaelni at gmx.at> wrote:
> 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.
>

The thp patch did not have any real review and it was just some fud propaganda.

For the brstm patch i really do not see any problem in commit log.
If there is policy that each commit log should explain everything even
for trivial
stuff also causing sending same trivial patch several times so commit
log is finally
accepted by random person that wanted (for whatever reason) to reply,
I will follow it.

> 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
>