[FFmpeg-devel] [RFC] About committership

[Stefano Sabatini]

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.

Amongst the changes, the most notable is the restriction of the
committership rights to a "committers/maintainers team" limited to the
self-proclaimed members.

The rationale for all the changes was:
"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."

No states have been done about how to actually achieve this objective,
and especially why this should be considered a "fair, productive
environment" for the developers which were deprived of their commit
rights.

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.

This is moving the commit burden on a limited number of
developers. This is not a good idea. To commit a change means in
general to do many steps:
* apply/update the patch
* test the change (make test, other ad-hoc tests)
* update docs/version numbers/APIchanges
* global pre-commit checks on the patch

The contributor is usually willing to do so, since she's motivated in
having the patch applied to the main branch, and is most of the time
the most competent developer about how to apply it.

I usually perform minor changes when applying a patch (commit log
fine-tunings, minor cosmetics), sometimes I even found some bug just
before to apply it, not being able to perform such changes is lowering
the quality of my own contributed patches.

If the committer is not motivated it will surely skip all these
passages, or it will delay the application of the patch. This is about
human nature, we tend to be lazy when not motivated enough, not taking
care of this aspect is a major flaw in the design of these new rules.

Having each developer a separate branch/repo doesn't help neither, as
I believed our gsoc experience in the last 3+ years taught, indeed the
main cost and the most difficult task is the integration of the branch
in the official repo, rather than the development of the branch
itself, which every kid with some git experience can indeed achieve.

Moving the focus of the developer from "getting the change integrated"
to "developing in her own branch" is not helping if the objective is
actually "getting the change integrated" in the main repo.
Also having each user to "cherry-pick" the changes from N branches is
not a good idea as well and will just multiplicate confusion and
mistakes.