[MPlayer-dev-eng] Commit rules and coexistence rules

[Michael Niedermayer]

On Wed, Jun 04, 2008 at 11:23:45PM +0200, Luca Barbato wrote:
> In the cvslog ml you may dig a thread in which we got lots of drama, 
> flames and assorted complaints.
> 
> I perceive the main issue being the intolerance to less understood rules 
> and scarce ability to get the rules accepted.
> 
> Let's try to address this before nuking Uoti out and other actions that 
> I consider not completely good.
> 
> Let's start with the commit rules.
> 
> Michael Niedermayer wrote:
> > On Wed, Jun 04, 2008 at 05:34:13PM +0200, Luca Barbato wrote:
> > These remove comments, remove outcommented code, ...
> > this definitly is not what indent does and its just what i quickly spotted
> 
> Ok, I overlook that mostly because is a big patch, you are right.
> 
> > And thats why such commits are so bad and why we all complain, they are a
> > nightmare to review, you missed the things above, others missed them too.
> > What if there where security related changes? Intentionally placed
> > buffer overflows or some, send /etc/shadow to badguy at badplace.com?
> > All code that goes into svn has to be reviewed or mplayer will become a
> > time bomb. Its trivial to get a svn account if one wanted to do something
> > nasty, reviews are the only way to avoid such issues.
> 
> I think we could start a revision of rules and just say that
> - A commit should be easy to review so it should be:
>    - small
>    - do not mix unrelated changes in a single lump
>    - possibly easy to follow
> - A commit message should be meaningful and to the point
>    - Terse enough
>    - Explain what the patch does.
> 
> - Exceptions could could go in if:
>    - They are discussed before
>    - They cannot be split w/out breaking functionality in the
>      intermediate commits.
> 
> Rules should help us getting things done and we should find them 
> reasonable and fair.
> 
> Uoti finds some of them annoying and cannot see the point of some of 
> them. I think most of them have a point but they should be clarified so 
> they can be understood by everybody.

The problem is not uoti not understanding the rules it is him refusing to
follow them. Rewriting them will not get you anywhere, i know, i tried it
they first claimed the rules unclear but when one tries to clarify them
they will attack you with being a "rule lawyer" trying to force everything
into strict unflexible rules.

In the end you are where you started, uoti commits what he wants no matter
if its a 80kb patch which he thought was just a reindent or some unapproved
change to files activly maintained by others ...
He does not agree with the idea of some kind or private space for
maintainers nor about spliting patches if it means extra work to him.
And especially (and i think this is worst) he does not care at all if
others complain about his actions and ask him politely to revert.

Once he even threatened a commit war if people would keep changing his
code so it can be compiled with gcc 2.95 that while at the same time he
does not see any problem at all to randomly commit to code maintained
by others ...

Either the rules are changed to allow such behavior or uoti will keep
breaking them unless of course he doesnt commit anything anymore.

My vote is still to remove uoti instead of changing the rules. Of course
i have no problem with clarifying them but any change that would make
the controversal commits ok are not something i would support.

just my personal oppinion as a mostly inactive mplayer developer
I hope i didnt insult anyone but i probably did as the subject cannot be
discussed truthfully without appearing insulting ...

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- 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-dev-eng/attachments/20080605/6ba1a0a9/attachment.pgp>