[FFmpeg-devel] [RFC] About committership

[Stefano Sabatini]

On date Wednesday 2011-02-02 12:33:13 +0100, Luca Barbato encoded:
> 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.
> 
> > 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.

It has been already said that the interpretation of those numbers is
flawed, provided the circumstances in which those committs
happened. Also note that most commits were done by developers which
were not active in the past few months, on the other hand if you count
the committs of the "previously active" developers which were not part
of the "takeover" you'll get really different values, indeed many
developers just stopped to contribute after the event.

But again, given the circumstances that data cannot be considered
significant, and in general the commit count is not necessarily
correlated with the quality, neither with the health of a project.

Also there are things which numbers cannot measure (for example how
much people are happy of being part of the project), but which are
nonetheless important.

> > 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 see this as a good way to make contributors work less.

This can be true for occasional contributors (for which I agree with
you), what I'm talking about is active developers, which care about
what they are committing and are doing a long time investment in the
project, so they naturally want the highest possible quality.

> > 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.
> 
> You are supposed to do that before hitting git-commit.

This needs a bit of explanation, I usually adopt a lazy approach, this
maybe can explain the low quality of some of my patches. Anyway I
don't work too hard for getting a patch in a perfect shape, especially
for complex ones, because I know that it will usually go through many
reviews, so making a big effort for creating a patch which will go
through many changes and which may be not even accepted makes no sense
and I try to spare me some work.

So I don't put too much effort when committing to my local branch and
sending, but I spend more and more focus when the patch is going
through the final revisions or when directly committing the patch.

> > 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.
> 
> You are thinking in svn.

Are you saying that by using git people cease to be lazy? ;-)

> > 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.
> 
> Because we were using svn. Rebasing on svn is costly, on git is easy.

Uhm I mentored two projects the last year, both students were using
git and it was greatly helpful, but still both projects haven't been
properly integrated, I know that this doesn't depend (only) on the
tools used, what I want to say is that better tools don't magically
deliver perfect solutions, and that some policy is required.

Also merges are easier, but still they require some effort, I need to
resolve conflicts by hand many times when I rebase my local branches
against the remote origin.

> > 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.
> 
> I'm of the opposite opinion
> 
> > 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.
> 
> The ffmpeg.org and possibly other target repos are here for this
> purpose, cf linux in this regard.

My idea is simple: one "official repo", with a stable and well defined
API/ABI which external developers can pick at any time and develop
against, and many repos which get synched from time to time. That is I
propose to apply to the main repo the same rules we applied to the
main SVN trunk.

API major bumps should be done possibly after "official" releases, to
reduce the impact on distros and other users ("company" users tend to
use official releases as well, especially when they don't know the
special nature of FFmpeg in this regard).

Then you can have many topic repos/branches, but yet you need to
define a mechanism and a policy for the synching, e.g. related to
API/ABI.

Suppose that I want to create a topic branch. At some point I have a
bunch of changes, after some rebasing the changes are in shape, and
the branch has been tested (how? I suppose FATE can be used with other
branches but the main one, but how much would it costs in terms of
configuration, bandwith, energy etc. etc. having N instances of FATE
one for each topic branch?).

Who is going to review the patches when they are going to be
merged, and who decide when and how to merge?

Also what if the branch you want to merge doesn't comply with the
rules for the main repo (e.g. in terms of formatting)?

> > From this point of view the "old" system was way better, as it was
> > letting to do the work to the persons which were motivated in doing
> > it, public changes needed to be discussed and approved by the
> > respective maintainers. Unreviewed changes could be committed by
> > threatening to apply in N days and finally applying them in case of no
> > comments. This worked quite well in the past three years I've been
> > into the project, with very few exceptions and intentional violations
> > of the policy, and with an high overall quality achieved.
> 
> I have the completely opposite opinion.
> 
> > 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.
> 
> > 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.

I pointed out some of the problems, the most serious one being that
many questions related to the policy and the governance of the project
have never been replied, this is *really* important when I'm going to
decide if I want to invest time and effort for contributing to the
project in its actual form.
-- 
FFmpeg = Fast and Freak Miracolous Philosophical Enlightening God