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

[Michael Niedermayer]

On Tue, Dec 18, 2012 at 07:58:29PM +0000, Paul B Mahol wrote:
> 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.

Thats how you see it and you reacted based on this view.
While iam sure derek had no intent to write "fud propaganda" and thus
saw your patch application and replies as a unprovocated attack on
him and reacted accordingly

Its good intent on both side together with different viewpoints
leading to the perception of the others bad intent and adjustment of
each ones behavior toward preceived bad intent.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/11ed85ae/attachment.asc>