[MPlayer-cvslog] r24941 - trunk/mplayer.c

[Ivan Kalvachev]

2007/11/12, Michael Niedermayer <michaelni at gmx.at>:
> On Fri, Nov 09, 2007 at 10:04:58PM +0200, Ivan Kalvachev wrote:
> > 2007/11/9, Uoti Urpala <uoti.urpala at pp1.inet.fi>:
> > > On Wed, 2007-11-07 at 15:32 -0500, Compn wrote:
> > > > can you give us a link or outline your 'good development policy' for us?
> > >
> > > I don't remember seeing many documents that could be called a complete
> > > development policy on the web. The only one I saw recently was the
> > > Subversion hacking guide, and I do not think that would work for
> > > MPlayer.
> > >
> > > > maybe there is something mplayer/ffmpeg team can add/remove from its
> > > > policy.
> > >
> > > Here are some things that I think could be improved in svn-howto.txt
> > > which is probably the closest to policy (though I wouldn't classify all
> > > these things as "policy"):
> > > - The svn cp hack for reverting doesn't belong in Subversion basics. IMO
> > > much of the other text in the "Reverting broken commits" part is
> > > questionable too. However in practice this comes up seldom enough that
> > > improving the text isn't too important.
> > > - There are parts implying strict code ownership by maintainers and even
> > > an explicit warning against against committing "trivial looking
> > > fixes" (wtf?). Those should be replaced by something more flexible.
> > > - The parts that are strongly worded against any indentation changes
> > > such as "If you really need to make indentation changes (try to avoid
> > > this)" and the requirement to even intentionally leave incorrect
> > > indentation in the file if the reindent required would be > 5 lines
> > > should be removed. The first priority should be the quality of the
> > > resulting code.
> > > - The instructions on how to write commit messages could be better.
> >
> > I repeat my proposal from 6 months ago to make Uoti project leader.
>
> he would be a leader with few followers, mplayer would be forked and
> most developers would leave and rather continue to work on the forked
> version, good changes from him would be merged bad ones would not
> the effect would be practically identical to closing his account and
> having him send patches

My evil plan is exposed...

I also would support the same people in the same order of preference.