[FFmpeg-devel] [RFC] About committership

[Michael Niedermayer]

On Wed, Feb 02, 2011 at 12:33:13PM +0100, Luca Barbato wrote:
> On 02/02/2011 12:10 PM, Stefano Sabatini wrote:
> > Hi all,
> > 
> > the recent coup imposed on all the developers a series of changes in
> > the policy which have never been discussed, not documented (indeed the
> > policy was never updated since the event), and not even explained, as
> > the new "committers" and the "undersigned" never felt the need to
> > explain the new system, although requested many times in the next two
> > following weeks after the coup.
> 
> By calling it coup you are making a specific statement.

I dont think calling it by what it is is making any statement.


> 
> > And now some considerations.
> > 
> > Having a limited number of committers is limiting the
> > productivity. Patches tend to lay unapplied in the mailing-list, when
> > there is no interest from the "committers team" to apply them, while
> > other patches for which they care are applied in a timely manner, but
> > sometimes missing quality checks from other developers deemed expert
> > in the affected area, whose "maintainership" status on the affected
> > files is mostly ignored.
> 
> From my data the turn around is faster by 10% while the number of
> patches left non discussed is smaller than before, could you please give
> numbers backing your statement? mine had been already posted.

the number of non whitespace patches droped to about half than before IIRC
and reviewing whitespace changes takes less time
and _alot_ of developers have left or refuse to work with the new maintainers
And dont forget the commits staying similar in number while alot of contributors
left was just because some people flushed out alot of old cosmetic patches
they collected over they years.


[...]
> > Now I see that the problem the new rules were trying to address was
> > avoiding having a single control point and disallowing vetoing
> > practice, indeed the new rules tell who can allow the commit (and
> > enforce it via the commit mechanism itself) but don't tell nothing
> > about who can veto the application of a patch (which I assume are only
> > the "committers" rather than the file maintainers).
> 
> the "veto" option is available to everybody.

I veto the libmpeg2 reader removial, the planed merging of libavutil & libavcore
I also veto people wasting time with libpostproc "cleanup" its just that,
wasted time both API and code are fine, cleanup will result in bugs and speed
loss and fixing these will cost more time. Noone wanted to work on this code
in many many years it doesnt all of a sudden need big changes.


> 
> > And finally my proposal: to review the committership mechanism, I
> > propose to restore the previous model, to give back commit rights to
> > all the developers and enforce *via policy* some of the new rules, for
> > example to require the approvation of non-controversial patches from
> > at least another developer with expertise in the area. The queueing
> > mechanism looks *good* and may be extended to all the developers.
> 
> I'd like to keep the current method for a bit longer and then see in
> retrospect what should be fixed and what had been really better.

The old system was far from perfect and needed improvments, we especially
needed more people reviewing patches and applying them, all that could have
been fixed but noone started even a discussion let alone vote to amend the
system
but the new system
is really broken as it totally lacks all conflict resolution logic, and the
leadership situation is left unspecified.
Anyone with a bit of politics knowledge knows horizontal leaderships or anarchy
dont work out and lead to dictatorships rather quickly. And in this case
it will be root to take the top seat even if not vissibly so.
And then i remember when chatting with ben that he felt the commiters as mere
patch monkeys who anyone with enough time could join, but from more chatting
with actual members of the commiter team they seem to rather think they lead
ffmpeg now and have actual decission power. Not that they said that clearly
but rather by how carefull they guard against people joining the team who
dont fully agree to their agenda

There is really just one way to describe the new system and that is a,
corrupted friendship economy. If you are in, great if not well you are out of
luck.

ive suggested me, carl, stefano, baptiste, aurel and reimar to join the
commiter team as part of a compromise, bens arguments against 2 of that where
just based on time constraints, ronald argued about "on the right side",
id love to quote what he said but then again they will point to me posting
"private" communication.
Its ridiculous, we now have political sides and people on the wrong one cant
join.

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

There seems to be only one solution to NIH syndrom, ... a shooting squad
-------------- 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/20110202/b40fd6f9/attachment.pgp>