[FFmpeg-devel] [ANNOUNCE] New FFmpeg maintainership

[Michael Niedermayer]

On Wed, Jan 19, 2011 at 01:58:53AM +0100, Diego Biurrun wrote:
> On Tue, Jan 18, 2011 at 11:39:24PM +0100, Stefano Sabatini wrote:
> > On date Tuesday 2011-01-18 19:53:41 +0100, Attila Kinali encoded:
> > > We, the undersigned, announce that as of today FFmpeg maintainership
> > > has been assumed by a new team.  Our aim is to facilitate the
> > > development of exciting new features in a timely manner while keeping
> > > high quality standards and above all to provide a fair, productive
> > > environment for developers and contributors.
> > 
> > I can understand some of the reasons for this change, and I can even
> > agree with them. But it should have been better to announce and
> > discuss publically on this list.
> > 
> > This hasn't happened, and this sounds higly unrespectful for all the
> > FFmpeg developers not involved in the change.
> 
> There is a time for words and there is a time for action.

And it seems there is a time for stabing people in the back, judging from
these actions


[...]
> The discontent reached the point where a fork was being contemplated
> and then planned, but it turned out that the momentum had soared way
> past critical mass and turned into a tidal wave of revolution.  The
> focus moved from forking to avoiding a fork if possible.
> 
> Since git was being set up on videolan.org, setting up an alternative
> git tree on mphq was the natural choice.  With development moving to
> videolan.org and such a large group of developers already part of the
> revolution keeping the infrastructure was the logical consequence.
> 
> Apologies if the speed and suddenness of our actions were a surprise to
> some.  The intention was not to exclude the people who did not receive
> timely notification, this is mostly a matter of timing and coincidence,
> not ill will.  We tried to contact almost everyone, but did not succeed
> with all.  Not everybody was on IRC, others, like you for example, did
> not answer the phone or react to SMS messages and/or email.

Seems i must have been missed too ...


> 
> It became clear that we could not wait much longer, so at some point we
> just moved forward.  Maybe things were rushed, possibly something could
> have been done differently, but we did not believe it would have made a
> material difference apart from long and drawn-out flamewars.
>

> We hope and expect to have done the right thing for FFmpeg in the long
> run and will work on turning the project into a healthy and welcoming
> development environment.

like mplayer after arpi was flamed out, id guess


> 
> Everybody is welcome and invited to join the community to work on
> FFmpeg, all past and present and future developers included.

Thank you alot for the offer.
Yet given the way this was done, without bothering to contact me, and
behind the scenes by the very team that became the "New" maintainers.
Thus giving them all chance to argue for them and against others without others
to even know about or able to defend themselfs from false accusations.
I must decline.
This is by a very far stretch below the belt line.
If people wanted a change in leadership this can be done easily by people
proposing options, discussing them and then voting about them. Or in case one
lacks a majority by forking.

PS: no ive not decided what to do now, it also depends alot on if the remaining
developers would support an alternative to the fork of the "new" maintainers.
That would be based on democracy and democratic elected leader, as well
as a reduction of bikesheding and politics and a return to that
"each maintainer is the boss about the part he maintains".
Of course all this is discussable, if people prefer
something else, kernel style or whatever i dont really mind as long as it is
practical. And of course everyone would be welcome to contribute there too

PS2: And it remains to be seen if these actions have the support of a
majority or not after open and public discussions about any arguments about it.

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20110119/42cc018a/attachment.pgp>