[FFmpeg-devel] [VOTE] FFmpeg leader

[Stefano Sabatini]

On date Saturday 2010-10-02 11:10:42 +0200, Reimar D?ffinger encoded:
> On Sat, Oct 02, 2010 at 11:00:06AM +0200, Stefano Sabatini wrote:
> > I believe we agree that maintainers are free to apply patches on the
> > files they maintain, but in general there should be some exceptions to
> > this rule. Such exceptions may arise when:
> > 
> > * the change affects the policy or the style of the project
> > * the change is no trivial, so it may benefit from peer-review
> > * the change affects other code not maintained by the committer *or*
> >   the public interface
> 
> Really, rules don't work here. It will just move the flaming to the
> interpretation of the rules.
> Of course we need some common view of how things should work in
> principle, but in the end the only thing that works is wanting
> to work together, taking into account criticism even if you think
> it goes too far without discussing forever who is right (unless
> you really think it goes far too far), and assuming the best intentions
> of the other side.

On the contrary I believe that would be important to settle the policy
once and for all, as one of the main reasons of this vote request is
related to policy violation and restrictions.

I believe most of us want Michael to stay as the project leader, and
we want Mans to continue to stay with his very much appreciated
contributions, so the problem is not related to the persons involved.

While I don't have nothing in particular to object to the FFmpeg
leader, I understand the point of Mans when he says that the leader
should abide the same rules that apply to the other developers, and I
can understand that this can't and shouldn't be literally true but
there should be some restrictions regarding his committing
prerogatives. Requiring the project leader to post some patches and
wait some time for review if the changes involved are important and
affect the public interface looks like a reasonable request, standing
that the project leader would have anyway the last choice on the
discussed changes.

On the other hand the other committers should respect the final
decisions of the leader, that doesn't mean necessarily to show or
declare agreement but simply avoiding to incur into commit wars and
reverting their changes when explicitely requested.

This won't avoid for sure bikeshedding or conflicts (that's mostly
related to the personalities involved) but at least should contribute
to create a more collaborative and "shared" environment.

> If we want a rule I'd say this one is it: do not argue about things
> that are not really relevant to the current topic (chose another
> time if you consider it important), and avoid arguments that will
> not help progress towards conflict resolution.

This is a meta-rule, whose interpretation is *much* more complicate
and controversial that some simple policy-related rules. Also
sometimes it is just better to focus on the conflict and try to solve
it rather than simply discarding it (that's another form of resolution
of course).

Just my 0.02?.

Regards.
-- 
FFmpeg = Forgiving and Fabulous Monstrous Puristic Elastic God