[FFmpeg-devel] [VOTE] FFmpeg leader

[Michael Niedermayer]

On Sat, Oct 02, 2010 at 04:49:28AM -0700, Jason Garrett-Glaser wrote:
> On Sat, Oct 2, 2010 at 4:41 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sat, Oct 02, 2010 at 12:39:11PM +0200, Stefano Sabatini wrote:
> >> 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
> >
> > I asked several times, and i ask again
> > which rule / part of the written policy has where been broken?
> > now after mans you start discussing about policy violation, and i really
> > think such accusation should be backed up by something
> 
> I've noticed a lot of stuff committed lately (per-codec parameters,
> the assert changes, swscale API changes, etc) that happened without
> any community discussion at all.  Many of these things are serious API

This is untrue
the assert changes have been discussed a long time ago with noone caring.
the per codec parameters too have been discussed and ive explained that
i plan to implement them through a priv_avclass in AVCodec and AVOption
access to the private context, noone disagreed from what i remember
and the swscale api changes have briefly been discussed in the IRC thread
that was triggered due to the 10bit dithering trolling. Yes the final
implementation was a hair differnt than what was discussed because its
simpler as it is now but it all was discussed.


> changes -- and even though everyone wants them, there should be
> agreement before they are committed.
[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101002/84ede809/attachment.pgp>