[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] CVS guidelines

From: Sebastian Hilbert
Subject: [Gnumed-devel] CVS guidelines
Date: Mon, 17 Nov 2003 21:31:40 +0100
User-agent: KMail/1.5.4

To all !!!!! developers,

Today something happened that never should have.
Large pieces of code were moved into the main trunk without informing the 
project admins and/or this list.

This is an absolute no no.

I am not a project admin myself but nevertheless will not restrain from 
submitting my comments.

I propose a set of guidelines which need to be established in order to 
successfully  continue GNUmed development. These guidelines are neither 
unbiased nor intend to be complete.

I suggest :

Whoever wants/has CVS write access follows these guidelines or CVS rights will 
not be granted or even revoked by the current project admin (not me luckily)

1.) start your work in test-area
2.) from now on all patches should be peer reviewed before comitting to CVS
3.) unreviewed patches will not make it into CVS (main trunk)
4.) comment your code ( and I mean comment everything even if it might seem 
stupid to you !!!! )
5.) uncommented code (new files etc. ) will not make it into CVS
6.) submit early and often / announce changes to the list
7.) be aware that huge patches will most likely be ignored by peer reviewers 
unless they agree with it
8.) do not mix tabs and spaces when indenting ( tabs are preferred )
9.) never commit files you did not change 
10.) add commit comments to each file you commit !!!
11.) take  a close look at what code is already there, use existing code 
whenever possible, enhance existing code whenever necessary
12.) wanna code your own client ? That's perfectly fine . Please stick to 
test-area for that

13.) whatever is missing
I want to hear your comments. If you intend you help ! GNUmed in the future 
raise your voice. By now you may think who they hell does he think he is !

A week from now these guidelines (or their successors) will go live (at least 
for me). Unless one of the project leaders tells me to shut up, I will stick 
around for some time to come and bug anybody who is not willing to follow 
some simple rules.

One thing we should keep in mind is: We (hopefully there is agreement on that) 
don't just reinvent commercial practice management software products. We 
intend to write better ! software even if that is a slow process.

These guidelines will be posted at and I hope any other GNUmed 
related website

Take care,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]