[Gdal-dev] RFC 3: GDAL Commiter Guildlines

[Frank Warmerdam]

Marek Brudka wrote:
> Hi,
> 
> Practice:
> 
> "When committing new features or significant changes to existing source 
> code, the committer should take reasonable measures to insure that the 
> source code continues to build and work on the most commonly supported 
> platforms (currently Linux and Windows), either by testing on those 
> platforms directly, running buildbot tests, or by getting help from 
> other developers working on those platforms."
> 
> sounds good, but is rather impractical. SVN is a kind of "communication 
> medium" between developers and operating systems. Moving manually files 
> between Linux/Windows to make tests as well as sending/receiving sources 
> to/from developers always lead to troubles with versions/line ends etc. 
> Moreover, efforts related with "new features or significant changes" 
> usually require a lot of additional work which should be versioned by it 
> own. A common practice for this case is to create and work on a private 
> branch in repository. I propose then to modify the recommendation in the 
> following way:
> 
> "New features or significant changes to existing source code should be 
> commited to separate private branches. Merging to the main trunk is 
> allowed only after testing them by separate developers on various 
> platforms."
> 
> 
> BTW. I do not think, that the requirement to have all branches 
> compilable and valid is reasonable. It is enough the have good sources 
> in the main trunk and/or in some important public branches.

Marek,

It was not my intention by the original paragraph to imply that the software
builds at all moments.  That is, I anticipated people commiting the code
when they are somewhat sure it works, and then promptly testing it on
other platforms from source control (as the buildbots do).  The point
being that if they commit something wrong, they should discover this soon
and have it fixed (say within an hour).  Rather than just waiting till
other developers update and complain.

If this aspect was unclear, and the PMC wishes, I can try and clarify this
in the text as an editorial clarification.

I'm personally not yet comfortable with this concept of private working
branches, and as such do not wish to incorporate their use into our documents
as standard practice.   I would agree that the "buildability" requirement
applies only to important public branches (ie. trunk and stable branches).

PS. The RFC was adopted.  I'd rather not re-open the issue for other than
editorial changes unless the need is fairly compelling.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org