[mb-devel] Reverting another developer's changes -- is it ok?

[Robert Kaye]

The official dev guidelines are currently being held up by me wanting  
to get feedback on a little known conflict that happened in the wake  
of the July 12 release. Please consider this change set:

http://bugs.musicbrainz.org/changeset/8270

In this case nikki reverted some changes made by Stefan because this  
is the only way she could see how to fix the issue. Ok, I am not  
interested in settling or getting involved in this particular  
instance. Since we did not have a commit/dev policy in place, I don't  
want to revisit this issue. I mainly want to see what people think of  
this.

In the future, is this acceptable behaviour for MB developers?

Next, I want to write up a commit policy for MusicBrainz as part of  
the dev guidelines. Lauri pointed out the FreeBSD and KDE commit  
policies as a point of comparison:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/ 
rules.html
http://developer.kde.org/policies/commitpolicy.html

I think the following points from the freebsd list look good for us:

    1. Respect other committers.
    2. Respect other contributors.
    3. Discuss any significant change before committing.
    4. Respect existing maintainers (ruaok: I think this should  
include not reverting other people's changes)
    5. Any disputed change must be backed out pending resolution of  
the dispute if requested by a maintainer. Security related changes  
may override a maintainer's wishes at the Security Officer's discretion.
    8. Respect all code freezes and read the committers and  
developers mailing lists in a timely manner so you know when a code  
freeze is in effect.
    9. When in doubt on any procedure, ask first!
   10. Test your changes before committing them.

 From the KDE list I like (augmenting the above):

   # Think twice before committing.
   # Double check what you commit.
   # Always add descriptive log messages.
   # The code you commit must adhere to the KDE coding policies.
   # Respect special commit policies set by the release plans.
   # Take responsibilty for your commits.
   # Don't commit code you don't understand.
   # Don't abuse your SVN account to push in changes with which other  
developers disagree.
   # Don't add generated files to the repository.
   # Don't use SVN keywords like Id or Log in the source files.

I'd probably start with these points and build our own commit policy  
from this.

If you have any thoughts, questions, feedback, please post them here!

--

--ruaok      Somewhere in Texas a village is *still* missing its idiot.

Robert Kaye     --     rob at eorbit.net     --    http://mayhem-chaos.net