[FFmpeg-devel] Preliminary announcement about the current situation

[Rob]

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.

It's like having 5 people trying to take on 500 people all at the same
time in a battle. It's not effective. Perhaps if 1 each takes on 1 or
2 take on 1 if the opponent is large some small victories can be had
more quickly. The small victories then add up over time. I guess my
point is I think we could have a better strategy to enable faster
progress of important things.

> I dont think we had or have a consensus to merge things that break things that
> currently work?

Definitely not. It was desirable to use ffmpeg-mt as the base for the
new direction but some of us were adamant that we should consult with
Alexander Strange as to whether it would be ready for prime-time and a
base for development. Merging it haphazardly is not the goal. We all
want the development branch to work well as much of the time as we
can.

> And i did add the pkt_pts/dts fields in AVFrame recently as a move
> toward getting the timestamp handling compatible with ffmpeg-mt so
> yeah i was slow but i was working on that

That's good. Perhaps others interested in -mt should try to help too.
Random helping doesn't work so well though, there needs to be
communication and organisation of who will/wants to work on what and
consideration of things that will interfere with each other.

>> That's not to mention that the environment is not welcoming to new
>> contributors at all. I believe that rather than forcing contributors
>> to make perfect contributions from the outset, they could be asked to
>> work on significant weaknesses in contributions themselves but for
>> something that is a small change and quick to do for someone who knows
>> how it should be done, the contributor should rather be informed of
>> the errors they made and the maintainer should make the necessary
>> edits and commit. The point is to _encourage_ new developers, not
>> force them to adhere to all our rules immediately.
>
> I agree as far as we have the man power to do such things but iam not sure we
> do have that

It would have to be proven but I'm thinking that focusing on
individual items until they are complete rather than spreading oneself
across many many items would accelerate the completion rate. Perhaps I
am wrong. Personally I find context switching with regard to tasks has
quite high latency but once I'm working on something my productivity
is high.

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

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.

>> Then we come to significant work on the core to make it simpler,
>> cleaner, more flexible and maintainable. Anyone who goes near
>> MpegEncContext comes back with bleeding eyes and a headache.
>> AVCodecContext is very large, albeit pretty well documented in the
>> header. libswscale may be fast but it's horrible to look at and work
>> with despite repeated attempts to improve it.
>>
>> When people want to work on such core stuff they really need support
>> and encouragement. Working on such difficult core constructs is
>> draining in and of itself without being met with resistance,
>> nit-picking and flaming. For the sake of progress rather than
>> stagnation, sometimes a good solution can be a step in the right
>> direction rather than waiting for a perfect solution.
>
> Thats true but some of things done in that area where steps that actually made
> the code worse and more convoluted.

OK, that's fair enough then. I do recall that you were not happy with
the quality of a number of attempts at contributions in these core
areas. I can fully understand that and it seems you agree that these
parts of the code are difficult to understand and work on to produce
some kind of elegant and correct result.

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

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

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.

>> Perhaps I had some more thoughts but this email is getting very long
>> already so I will finish with this - ultimately I respect and
>> appreciate all that you, Michael, have done for the project. However,
>> I do not believe you are a leader as I do not believe you offer
>> significant high-level direction to the project - that is, you were in
>> the driving seat but where were you driving us?
>
> Where we wanted to drive to.
> Where we had someone willing to do the work and maintaining ...
> I generally left the direction to the interrests and existence of volunteers.

And that is something to preserve in a sense. None of us want to have
what we work on during our free time absolutely controlled and
directed. However, I think that helping to guide people so that they
can effectively achieve the goals they wish to achieve is what is
really needed. A community working together and helping each other.

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

I will profess that portability is not something I am so well versed
about and something I should learn. In my situation I feel that I have
to be humble about my contributions and expect that there may be
issues in the code I have written of which I was unaware. At the same
time it is counter-productive to force someone to spend a lot of time
learning about portability issues. I rather feel that they are
something that could come with experience.

Not all of us have the time to read through relevant documentation
regarding portability and portability standards to the point that we
can recall it all when writing code. This is a point where I think
perhaps it would be quicker for M?ns to point out the issue and
perhaps fix it himself or at least tell the person how to fix it
themselves or point them to the precise piece of appropriate
documentation or at the very least to the document and what to look
for.

It is not my intention to single out M?ns, he is but one example
amongst many. Regardless, it's happened, it's in the past. The point
is to each try to be constructive and helpful in your reviews. Think
about what you can do to help the person whose code you're reviewing
to address the issue of concern and to remember how to rectify it in
future.

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.

Contributors need to be patient and humble too. This goes a long way.
Aggression is often met with aggression in the human condition. Maybe
it's a survival technique that many people have, I don't know. I don't
think it's useful though. It causes problems to escalate. If met with
aggression, try being constructive in response and see what happens.
:)

> These growing attacks against me has been the very main reason for my
> offensive behavior and flaming against people. I plain and simple wanted to
> work without having to go through all the bikeshed review taking more time
> than anything else. Maybe its the curse of a leader that his patches are
> read by more people than others and that more people reply with their
> oppinon on a better function name, better whitespace placement, other way
> to rewrite the whole that isnt really better but one is labeld as stubborn
> for not doing it.

I don't think it's the curse of the leader, I think that pretty much
all contributions are subject to the same scrutiny. I know of
situations where I and others have been asked to rename functions and
variables despite perhaps being named after what was in the some
specification for easier referencing while developing. The goal was
more comprehensible code and that's a subjective thing.

Regardless, some people place importance and priority on things that I
don't. It's the same for you and everyone else in the project no
doubt. We can perhaps work on some compromise or have some protocol or
tool to aid us. Or we just have to learn to work within the desires of
others to have the privilege of contributing to the project. It can be
awkward, maybe some people find some things harder to adjust to than
others. It's difficult to know what to suggest without addressing a
specific case.

One thing I will note and I hope it doesn't cause a fire bomb to be
hurled at me - GStreamer has an indent script that must be applied to
all code before it is committed. I personally found the chosen style
quite easy to adapt to and I can normally write my code to be
formatted correctly without the aid of indent. Perhaps some people
prefer to disregard formatting and let the tool do it all, that's
fine, it looks the same in the end. Commits not adhering to the
formatting will be rejected by a pre-commit hook. While in some cases
it doesn't work (vertical alignment of assignments is ignored, some
weird line breaks in structure member references, etc) on the whole it
saves a lot of needless argument and produces very consistent looking
code. Maybe it's something that would save us all a lot of time and
effort.

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

I even think that the people who might think they want you to leave
and have some mindset of "either he leaves or I do" don't really have
any personal issue with you but rather have built up frustration and
negative emotion from past encounters where both sides have been
negative, destructive and arguing in a frustrated and flaming manner,
attacking each other for long periods of time. Speaking from a place
of anger or hurt and with that in mind, one way or another, they're
going to not want to work with the cause of that emotion. This is just
as you feel now.

It doesn't have to be that way. We can take some time and space from
each other, try to approach the problem again and, to quote Gandhi,
'be the change you want to see in the world'. Do we want to be
aggressive and mean to each other? Do we want to be pedantic and
nitpick at the small details repeatedly when it's not really necessary
to do so or the details could be addressed more effectively? Do we
want to help each other to be more effective at the things we do? Do
we want to have fun while we do it?

> anyway i wanted to repeat that iam glad that yours and some of the other mails
> are written in a non offensive tone. Iam feeling crappy enough after the last
> few days

*sincere hug*

I have no interest in flames nor making people feel bad. I have
campaigned against such on multiple occasions during my involvement
with the project and elsewhere. I don't intend to stop. :)

Best regards,
Rob