[FFmpeg-devel] Preliminary announcement about the current situation

[Michael Niedermayer]

On Thu, Jan 20, 2011 at 07:45:12PM +0100, Rob wrote:
> On 20 January 2011 14:00, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Thu, Jan 20, 2011 at 12:46:14PM +0100, Rob wrote:
> 
> >> Nevertheless, I thoroughly support the end goals of the change. As
> >> stated by others, FFmpeg is _not_ MPlayer. I used to follow MPlayer
> >> development quite closely and it's where I started out in my
> >> development path really. These days I am not interested in the project
> >> at all and don't follow its mailing lists. Why? Because it ceased
> >> being fun and all the really interesting and original stuff was being
> >> done, and done right, in FFmpeg. MPlayer was a never-ending flame war,
> >> it felt very negative and stale and I was just waiting for FFmpeg to
> >> supersede it.
> >>
> >
> >> Why is any of that relevant as it is about MPlayer and MPlayer is not
> >> FFmpeg? Events over the past months and even years in FFmpeg were
> >> tending to the same end. Endless flame wars, alienation of very
> >> significant and productive developers who were not even ignoring the
> >> project rules and policies, lack of progression in areas that really
> >> need it and the whole project was progressing very slowly due to
> >> significant contributions taking far too long to get into the main
> >> repository. The development environment has not been so positive nor
> >> productive for active developers.
> >
> > yes, but the lack of some complex things like ffmpeg-mt being intergrated
> > is that on one hand they are not free of issues and on the other theres a
> > general lack of manpower.
> 
> To some extent, yes.
> 
> > What do you think i could have done about these?
> 
> I don't think it was your responsibility to personally work on these
> things to get them merged, I think it is rather a problem with the
> general approach of the review process that we have had in that the
> reviewers just review and don't do coding themselves to help reach the
> goal of getting the patch set merged.
> 
> Maybe I'm naive but for something as important as ffmpeg-mt I feel
> that people should work together to try and get whatever is necessary
> done more quickly. Git should be a major helper in such collaborative
> development processes. I think it is really the lack of manpower and
> the lack of team focus on significant developments that hinders our
> progress. Each person was working on one thing. Very few people were
> reviewing the things on which those people were working on.

The ffmpeg leader would have been able to merge ffmpeg-mt or help in doing it
together with alexander
before his colleges and friends decided to stab him with knifes, that is


[...]
> >> Consider you're making an initial contribution to a software project.
> >> You've had a relatively small idea for a change and implemented it or
> >> encountered a bug and fixed it. You make your contribution by sending
> >> a patch to the developer mailing list...
> >>
> >> A. Your patch goes through 2 rounds of review and you make changes
> >> according to the reviews given. The reviewer tells you of some more
> >> minor things you need to change in future but they have done them for
> >> you this time and they thank you for your contribution.
> >>
> >> B. Despite being a small change, there are lots of minor issues you
> >> have to address and your change is going through review after review
> >> after review. Eventually it gets to a point where the reviewer is
> >> happy that it is committable and it gets committed. The patch went
> >> through 10 or more rounds of review.
> >>
> >> In each case, how motivated do you feel to start work on another
> >> contribution? Situation A is contrived. Situation B I have seen many
> >> times within FFmpeg.
> >
> > I can understand you very well here and fully agree. Many of my patches that i
> > sent recently as well as commits have been hit by a quite similar wave of
> > nitpick reviews. This also was the begin of my fight with mans, where i felt
> > highly offended by his continous nitpicks about my commits & patches.
> > I flamed back, he flamed on IRC and from there it was a downward spiral we
> > know
> 
> It is good to know that you feel the same about the bikeshedding as
> basically everyone else. I suppose the thing isn't to compromise
> quality in terms of bugginess, stability or security but rather to
> allow some things that work and are tested to enter and to work on
> them while they are in use. That is, rather than reviewing until
> something is 100% awesome, maybe accept 80-90% awesome and work on the
> remaining 10% as time permits. At least then in the meantime one can
> benefit from the 80-90% awesomeness rather than not at all.

of course


> 
> The arguments against are for the special cases where something needs
> to be done properly like porting libmpcodecs filters perhaps or
> improving our own AAC decoder rather than relying on external
> libraries. I think most of the concerns there are about 'quick hack
> stop gaps' or so. It's a difficult line to define but I think that so
> far we have erred too much on the side of hindering progress.

yes, though that wasnt always like that, i remember various codecs in the
early days to be commited with just intra pictures working and the
rest to be implemented later


[...]
> > Cleanup of stuff like MpegEncContext and surroundings needs someone who knows
> > the code or someone who has enough brains, time and will to learn it (everyone
> > lacks one of the 3 it seems)
> > Otherwise cleanup turns in bugup and bogus restructuring that actually can make
> > the code alot worse structured than before
> > (and no iam not speaking about the swscale work now, that ive not looked at
> > ?and id suspect it be ok, swscale is simpler)
> 
> In that case, and this is a really important example, what I said
> above should apply to _you_. That is, as you understand these core
> parts of code and recognise that they need work, other members of the
> project should support _you_ so that you can work on these things
> until they reach a satisfactory level. Whether that level be where
> they are clean enough to comprehend by more people so that others can
> help or whether that mean that the job is just close to being 'done'.

Maybe its me but i feel it a bit rude that the people who are behind the recent
actions ask me for help. Thats not at all addressed to you personally but more
generally.
I dont need MpegEncContext and code using it cleaned up i understand it quite
well after all i wrote most of it. And i wont help people who strip my title
off me and hijack ffmpeg.org
There are many things to do, there are many FOSS projects and many things
unrelated to FOSS.


> 
> >> FFmpeg still doesn't have ffmpeg-mt merged, it doesn't have audio
> >> channel mixing code, the above-mentioned stuff is a mess,
> >> documentation is lacking, the bug tracker and website live in the dark
> >> ages and documentation is significantly lacking. I lent my support to
> >> the goals of the 'new team' because I believe that they are better
> >> equipped between them to provide a professional, productive
> >> environment that allows and even encourages progress in the areas that
> >> really need it rather than holding it back due to endless minor
> >> issues.
> >
> > All fine just one thing i object to and that is you implying that the
> > previous team held things back due to minor issues.
> > Where exactly did i do this? Yes i did do it years ago but i mean recently
> > Ive honestly tried to avoid this kind of behavior and you can also surely
> > see that for example jasons patches recently they mostly where approved by
> > me in the first round
> 
> That you tried to avoid the behaviour is admirable and appreciated.
> 
> Honestly, my commentary is not an attack on you. I do not think you
> actively caused the situation we ended up in and I do not think you
> are to blame for it. We can probably all recognise that reviews do
> receive a lot of nitpicking and are slowed down because of minor
> issues. I do not lay this solely on you at all.
> 
> I do however think that the approach to leadership that you took,
> allowing completely free development focus which could well be
> admirable in an Open Source project, does not help steer the project
> as a whole away from such a situation but rather allows it to flow as
> it wishes.

It effectively finds the lowest energy path by freely flowing


> 
> Put a group of intelligent, knowledgeable and naturally pedantic
> hackers together who all strive for the very best and it seems like a
> completely natural end point. We're trained to have an extremely acute
> attention to detail while considering a very broad target user base
> and solving very complex problems. How can it not be natural that if
> left to run free such people would conduct themselves in the way they
> are trained? I am definitely included in this and I have to watch
> myself in daily life that I do not become obsessed with being right
> and to enjoy the ebb and flow of humour, creativity, subtlety and so
> on.
>

> You cannot and should not be blamed for the path the project followed.
> but it seemed very clear that a change in organisation was necessary
> to snap us all out of it and to do better for ourselves.
[...]
> >> It is not for me to decide what you do, but I think many would
> >> appreciate if you coded much more and reviewed much less. I have the
> >> perception that you felt a lot of pressure and responsibility for
> >> reviewing contributions. Not many others did it and certainly not to
> >> the extent you did. Trying to review close to every contribution to
> >> FFmpeg as just one man is too much. I think you and the project would
> >> benefit from you writing code rather than reviewing and exerting your
> >> levels of optimisation on all contributions.
> >
> > I have over the last days and even months before that when attacks and
> > nitpicks against me (and no doubt avoidable flames from me as a result)
> > where increasing thought about my position a bit.
> > And it kept becoming clear even longer ago that i cannot contribute code
> > anymore as people like mans would filibuster and nitpick every patch and
> > commit from me to the point where i ended up spending 2 times more time
> > on getting it ok-ed by all than it took me to write it
> > The lastest libmpcodecs patchset is a bad example as it is special but it
> > shows the effect quite well.
> 
> I hope that the conflict between you and M?ns can be overcome such
> that we can all move past these bad times, change the way we do things
> and try to be constructive and positive. I know I sound like a hippy -
> peace and love maaaan. But I know M?ns has significant concerns about
> portability and POSIX standards and such. M?ns seems to know them very
> well.

Iam not sure about the conflict between me and mans, when i tried to
resolve the conflict by writing him mails i got no replies.
Now he is involved in the domain and server hijacking and given these
circumstances i see resolution as quite hard.


[...]
> Is it quick for you to do yourself and potentially very slow for them
> to do? Maybe inform them about it and do it yourself this time. If it
> is a repeat offense, maybe request that they do it themselves this
> time. This will probably encourage a humble contributor to contribute
> again and to remember to address the issue automatically in future.

good ideas


[...]
>
> > So really i had wanted to get my personal fork to work freely or just leave
> > ffmpeg.
> > Given that all people i had a problem with now are on the new team, and i
> > dont seem to have much support left, i fear this is going to end in me
> > leaving the project. Contribute is not fun with ones code going through the
> > amount of bikesheding and nitpicks mine has gone through lately and my
> > personal fork with myself having so little support would probably just rot.
> 
> It depends if the situation has to be that way. When it comes down to
> it, I think the vast majority of people involved in this project would
> be _really really_ disappointed and sad if you were to leave. I think
> this is a horrible situation to be in and I can completely understand
> that you feel betrayed, disrespected and hurt by these events. I
> apologise for my part in that though I think my apology is worthless,
> I just have to not do it again.

Well if i wasnt striped of my BDFL hat and that hijacking of ffmpeg.org
didnt happen then we wouldnt be in this situation.

anyway, you write long mailsa and  very nice and friendly ones
and i hope my awnser does not sound too offensive at points but they are
difficult matters to write about in non offensive way i think

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110120/fa4e1baa/attachment.pgp>