[FFmpeg-devel] Preliminary announcement about the current situation

[Alexander Strange]

On Thu, Jan 20, 2011 at 1:45 PM, Rob <robert.swain at gmail.com> 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.
> 
> 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.

My answer was that -mt trunk is not immediately ready to base development on, because 'make test fate' fails, and not release quality, or else I would have sent it here already.

But it is much easier to get it to development quality than release quality. And once it's there, I'm confident my bug list[1] is complete, so dumping it all on trunk will hopefully motivate/annoy other people into helping fix it the rest of the way and do VP8/etc in the meantime. That is the large part of what I agreed would be a good idea? but it might count as haphazard merging, because head of svn was always (I think) considered to be release quality at any moment. Moving forward on this or other large things like ffmbc might mean reducing quality for a while and then fixing it later. But this announcement doesn't seem like it covered this - unfortunately I think a few different things were discussed and then got lost.

But what I should mostly point out is that -mt is delayed due to not spending time on it (by me and others), not due to review fights. I'm working through the comments from Michael on the last patch set now and they're very good. In this area in particular I'm not sure any other project developers could do such a good job. That said, I would have been more willing to send work to mainline if I wasn't afraid of constant reviews while I was still figuring it out, but that's in the past.

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

Looking at it I feel like I should have thought of it?oh well. It's working fine for me.

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

Michael, do you feel like venturing out to FOSDEM?

[1] http://gitorious.org/~astrange/ffmpeg/ffmpeg-mt/blobs/d2f8287d8526f814bcc88d827775d39ddc5c5f22/mt-work/todo.txt