[Pipet Devel] Development model proposal

[Brad Chapman]

Hello everyone;
    I was thinking a bit about cvs and development and stuff like 
that, and I thought it would be cool if we could kind of sketch out a 
plan for "how to work on piper cvs" so that we can make development go 
in as smooth a way as possible. I think this is important because we 
are going to have more people working on the same program, so I just 
wanted to try and make things go as smooth as possible. Towards this 
goal, I came up with the following points as an idea for how we should 
try and deal with cvs:

1. Only check in code which doesn't break the compilation/working of 
piper. That is, don't check in code which is going to require other 
people to fix it before they can work on their stuff. This doesn't 
seem to be a universally accepted way of doing things, but I think it 
is very nice. This doesn't mean that code has to be "perfect" to check 
in, but rather that there aren't any glaring issues that will be 
immediately a problem as soon as someone else tries to compile/run the 
cvs code. 

2, Check in small chunks of code and changes frequently, rather than 
doing a lot of coding on your local machine and then trying to check 
it all in at once. This is also not a universally accepted way of 
doing things. For instance, on the bioperl project the way things work 
is that people work on big sections on their local machine for a long 
time and then try to merge it with the code in cvs. I think this way 
is a pain, and checking in frequently helps us to find bugs in each 
others code before they get too far.

3. Always write your changes in the ChangeLog, even if you only 
changed something very small. This way, if something isn't working, 
you can figure it out from the changes, instead of having to try and 
mail around to figure out what is going on. Something I haven't been 
doing, but which I think might be a good idea, is to also put the 
ChangeLog info into the cvs log message, so it is visible in cvsweb, 
and also if people like to browse log messages.

This model requires people to update from cvs frequently, and make 
more cvs checkins, but I think this is nicer than 
duplicating/overlapping work that has to be merged.
    What does everyone think about this? More suggestions? Opposition 
to my suggestions? Profound pearls of wisdom?

Brad