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

Michael Niedermayer michaelni at gmx.at
Mon Nov 12 00:42:25 CET 2007


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

anyway, this is not intended as flame, please dont misunderstand me,
this is just what i belive would happen, also i dont think uoti would
have much support to become project leader, reimar would definitly have
more support, i for one would vote for reimar at least, or roberto or
arpi if they had the time and interrest to be mplayer leader
rich also would have my support if the above ones wouldnt be on the
voting card
and there are many more i think may be a good choice as leader ...
and many i think would not be a good choice either due to lack of
technical knowledge of the mplayer code, lack of coding skill, 
lack of acceptance from the other developers, lack of time, ...

i surely lack time, also my knowledge of many parts of mplayer is not
good then again i dont think anyone really understands all parts of
mplayer but iam sure reimar and roberto understand the mplayer codebase
better than i do ...

anyway this is getting really off topic and i really dont want to start
a long flame thread, its all just MHO ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20071112/75cded3e/attachment.pgp>


More information about the MPlayer-cvslog mailing list