On 10/10/2012 10:49 PM, Etienne Tourigny wrote:
Hi Even,
On Wed, Oct 10, 2012 at 4:24 PM, Even Rouault
<even.roua...@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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
