No subject

[bogus at does.not.exist.com]

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.

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

BTW, but unrelated to the subject, the famous announcement was about
leadership but again no statement was done about how the project is
led now, and I liked the bazaar-style model followed before, every
developer working on her own interest area and indeed "leading" in
that particular area, indeed Michael was more a "project maintainer"
than a "project leader", the current model is more centralized since
it forces a limited number of developers with total control over the
commit process, which are significantly also the same developers with
total control over the rest of the FFmpeg infrastructure.

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.
-- 
FFmpeg = Fantastic Foolish Multimedia Puritan Erotic Governor