[FFmpeg-devel] [RFC] About committership

[Janne Grunau]

On Wed, Feb 02, 2011 at 08:49:14PM +0100, Stefano Sabatini wrote:
> On date Wednesday 2011-02-02 12:33:13 +0100, Luca Barbato encoded:
> 
> 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.

Please consider that many weren't happy before the change otherwise we
wouldn't have done it.

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

Make the patches you send or resend already highest 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.

This is a problem. It was already a problem under the old model. You're
wasting a scarce resource (review time) because you're lazy. I suspect
it is even more work for yourself since you have to go through more
review cycles.

Janne