[fdo-dev] FDO bugs, fixes and reviewing

Traian Stanev traian.stanev at autodesk.com
Fri Aug 25 10:36:12 EDT 2006



I completely agree with Frank, and he said it in a much more articulate
way than I could have.

Traian
 

-----Original Message-----
From: Frank Warmerdam (External) 
Sent: Friday, August 25, 2006 10:26 AM
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] FDO bugs, fixes and reviewing

Dan Stoica wrote:
> It may be much quicker and easier but it may be not the correct thing 
> to do.
> Say somebody else is doing a sync and runs into problems. Then he/she 
> will want to revert the changes to the previous revision - which is 
> not a pleasant thing to do.

Dan,

This is of course a situation I live in every day on every other
software project I work on, and I don't generally find it that
uncomfortable.
Occasionally sloppy commits may break a build (or operation) of software
and I will either fix the problem (if it is straight forward), or
regress my local copy till the problem is fixed if needed.

I will of course follow the FDO development rules to complete my
contract.
But it is unlikely I'd be interested in future unfunded work on FDO
under a "zip, review, then commit" policy.  This sucks the joy right out
of making a little improvement.

> The goal of the review is to a) get good ideas for free and

A post commit review can also provide good ideas, and with a reduction
in overhead it will be at least closer to free.

 > b) minimize the risk of breaking existing code.

This is certainly accomplished.  However, if the goal is ensuring there
is a "stable development version", this could also be accomplished
maintaining a branch which is basically the "trunk" but only updated
after a review.

I'd add that different policies might be appropriate for fdocore, vs.
providers.

> As for " having to zip up source files with correct paths is a pain"
> there is an utility \GRANITE\packchanges.bat that eases the pain :-)

I'm not too sure where/what \GRANITE is, but even if I had that script,
I generally try to do my development on linux and I suspect it won't
help me.

Overall I am happy enough to shelve this discussion for now, but I think
it will need to be revisited by an FDO Project Steering Committee once
such a thing is formed as part of OSGeo incubation.  At that point I
will no doubt try and promote a process that tries to encourage
contribution and involvement with a manageable level of overhead.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org For additional
commands, e-mail: dev-help at fdo.osgeo.org







More information about the Fdo-internals mailing list