[FFmpeg-devel] Preliminary announcement about the current situation

Michael Niedermayer michaelni
Thu Jan 20 14:00:30 CET 2011


On Thu, Jan 20, 2011 at 12:46:14PM +0100, Rob wrote:
> On 20 January 2011 04:53, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Wed, Jan 19, 2011 at 01:12:54PM +0100, Michael Niedermayer wrote:
> >> On Wed, Jan 19, 2011 at 12:54:48PM +0100, Herv? W. wrote:
> >> > On 19/01/2011, Michael Niedermayer <michaelni at gmx.at> wrote:
> > [...]
> >> > > Of course its their full right to fork if they see the need for that but
> >> > > thats
> >> > > not exactly what they did.
> >> > >
> >> > > And that I and everyone i spoke with dont even know the reason behind this
> >> > > move
> >> >
> >> > Have you asked any of the undersigned of "[FFmpeg-devel] [ANNOUNCE]
> >> > New FFmpeg maintainership" ?
> >>
> >> maybe not but they surely have seen me asking here in public and can awnser
> >> here
> >
> > Apparently not a single developer who signed this feels the need to say why.
> > They are all subscribed and all have read this
> > I guess i did not spend enough years of my life working on ffmpeg to deserve
> > an awnser
> 
> Firstly I would like to say that I sincerely regret the way this was
> conducted in the end. During discussions I was concerned about
> presenting the opposition in a dignified and respectful manner,
> maintaining due consideration and respect for others. Somewhere along
> the way I allowed myself to be blinded by the momentum of the proposed
> changes and neglected pushing for the final announcement to be a
> proposal for changes rather than an assumption of power. I am
> responsible for lending my support to this process and I'm
> disappointed in myself that I allowed that compromise to get through.

It makes me happy to read these words from you


> 
> 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.
What do you think i could have done about these?
I dont think we had or have a consensus to merge things that break things that
currently work?
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 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


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


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


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


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


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

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

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/9b9b61b3/attachment.pgp>



More information about the ffmpeg-devel mailing list