[gdal-dev] [update] Re: Travis CI continuous integration service for GDAL

[Ari Jolma]

On 10/10/2012 10:49 PM, Etienne Tourigny wrote:
> Hi Even,
>
>
> On Wed, Oct 10, 2012 at 4:24 PM, Even Rouault
> <even.rouault at mines-paris.org> wrote:
>
>> My feeling is that the main barrier to contribution lies more in understanding
>> how the source works rather than the tools around.
>>
>> Anyway, whatever the VCS, as you underlined, you still need competent eyes to
>> review, comment on, fix by themselves the patch or ask the contributor to do
>> changes, apply, or reject patches... Trac has already such patches waiting.
> I'd also say - if it works don't fix it.  Transitioning to git(hub) is
> certainly possible (QGIS managed to get it working well), but it will
> entain some productivity loss in the short term.

Just a small, probably very controversial, comment on this issue. If 
something works but you don't understand how or why, then the situation 
is very dangerous. You can get to this situation also when someone 
knowledgeable leaves. I would say that for example the swig part of GDAL 
is very difficult to grasp - there simply are so many moving parts. 
Thus, some development effort should be put into fixing working things.

I once did a test to re-organize (sanitize ;) the swig tree of GDAL - 
this is still in the sandbox. I also don't know enough of Git to know 
whether tests or forks like that would get more exposure or testing, but 
I'm interested in it. There are also some major issues that could be 
tested with GDAL (for example dynamic run-time loading of drivers like 
modules are loaded into Linux kernel, or XYZM support) - if these things 
could be developed and tested better with Git, I'm also interested.

Cheers,

Ari
https://github.com/ajolma