[Gdal-dev] RFC 3: GDAL Commiter Guildlines

[Simon Perkins]

On Wed, 01 Nov 2006 18:10:54 +0100, "Marek Brudka" <mbrudka at aster.pl>
said:

> > PS. The RFC was adopted.  I'd rather not re-open the issue for other than
> > editorial changes unless the need is fairly compelling. 
> As usual Frank. When you lack arguments you choose force solutions.
> 
> Marek

Marek,

Insults are not called for here. The RFC was proposed and voted on by
the GDAL committee (not just Frank) in accordance with the RFC
procedure. You did not object at the time. Frank is one of the the most
careful and conscientious software maintainers I have ever encountered,
and he is merely pointing out that if something has already been voted
on and formally adopted, then it's not reasonable to substantially
change it. Which isn't to say that new procedures can't be voted in that
supercede the old ones. It seems to me that the detailed branching /
tagging policy is not really covered by RFC 3. If we want to come up
with a policy or set of guidelines for this, then we should open a new
RFC to discuss that. Feel free to do so, and let's discuss the issues
like civilized people.

Cheers,

Sy

P.S. For what it's worth, I've played around a bit with more frequent
branching under CVS, and I agree that there are times when it's useful.
For instance, when working on an experimental feature from multiple
different machines - the private branch gives you a convenient way to
check the half-finished code into a central repository without upsetting
anyone else. On the other hand, under CVS at least, it required a
certain amount of discipline to make sure you always made sure what
branch you had checked out, and were careful with merges and so forth.
I've screwed up and lost edits at least once by not beng careful.
Perhaps SVN makes things more robust, but in any case, if we do have an
official policy of encouraging branches for major changes, we should
carefully analyze the pros and cons, and we should explicitly describe
the explicit procedure for doing things properly using the most common
SVN clients.