[Gvsig_english] Call for Mac Community contributors.

[Jorge Gaspar Sanz Salinas]

El 26/05/2011 11:00, Jordi Torres escribió:
> Hi Jorge, Joaquin, and Manuel:
> 
>     We've been discussing here Manuel, Joaquín and me and well, we think
>     your approach is not the best way to improve the gvSIG code. When one
>     needs to do changes or improvements on the code branching should be the
>     last resource as you are taking the decision of work aside the rest of
>     the developments, aren't you?
> 
>     IMHO it is more reasonable to try to improve the current code for
>     everyone and maybe do some work to plug your work on a separate
>     extension if it's only for the Mac distro.
> 
> 
> There are points where I cannot see a way, for example when loading ecw
> layers. At this moment we are using Gdal plugin to load this layers.
> gvSIG for linux and win uses a shared library present in the code. How
> would you face this problem? In the other side the ui changes could be
> sensible in other platforms, beacuse it could imply some dialog type
> changes. I am not supporting to branch the whole gvSIG, only a few
> projects, where the code is sensible to have impact over the other
> distributions.
> 

mmm allowing you to branch the trunk to let you develop or modify
several gvSIG projects is a point that should be discussed by the TSC
board. As I said I would prefer to see the development more integrated
into gvSIG current code instead of doing branches that who knows how
they will be synchronized with upstream in the future, but maybe I'm not
the best guy to discuss on that as we have other Board members here with
more gvSIG development and code maintain background than me.


>     Some time ago this kind of work was done to add flexibility to the
>     documents gvSIG supports from the initial view/table/layout to add
>     support for 3D documents (3d view and animation). Besides 3D, this work
>     was nicely used at other developments (as the publishing extension)
>     proving that the decision was perfectly right.
> 
>     For example, if you find a panel that is not well displayed on Mac,
>     probably will be because the layout management of it is not well done.
>     Do you think is better to just hack it to work on Mac right now or just
>     improve it to the benefit of all the other platforms (present of
>     future). I know it's more work, but the point here is doing the thing
>     right or quick?
> 
> 
> As I said to you we will need to change some dialog types, and maybe we
> have to do changes that are sensible to other distributions. Where we
> can avoid to branch, we won't branch. And be sure that if we find a bug
> and is in our hand to send a patch we will do it. In fact we are sending
> patches already. 
> 
> I think the real point is, in a short term (gvSIG 1.x), to have a
> distribution fully usable in Mac (yes, hacking code and whatever). And
> in a mid-long term (for gvSIG 2.x) to have a fully integrated and
> official Mac version.  IMHO is a waste of time (of our spare time :) )
> to do all this work in 1.x version.
> The other point is that right now we are only two developers willing to
> collaborate, Rafa and me. So we think our target in a short term is to
> get a full usable version of gvSIG 1.x. The more developers join us, the
> better we can do this work.
> 
>     Well my personal opinion is that OSOR wiki is quite crappy. I would
>     recommend you to use Sphinx[1] so you write all your documentation in
>     reStructuredText (wich is a great markup language). You can maintain all
>     the docs at the SVN and then rsync the generated HTML to the static
>     upload area of the project.
> 
> 
> Jorge you know I don't like osor too, If I proposed to use osor is to
> give a consistency with the rest of the project. There are a bunch of
> wiki frameworks and repository options that we can utilize, but it makes
> sense to do it in osor, or in the gvSIG plone. In fact you know I prefer
> to move to git, and this is not possible in osor. Anyway I will take a
> look to Sphinx.
> 
> I am agree with you to use RST.   

Well my proposal is to still use OSOR, but not the GForge wiki but using
rst documents at the svn and static generated html uploaded.

Anyway that was just an idea. For me the key point is to have
documentation about the people involved on the working group, the
workflows and procedures, etc. Use whatever is usable for you.

-- 
Jorge Gaspar Sanz Salinas
gvSIG Team at Prodevelop
Technical Collaborations Manager
http://www.gvsig.org
http://www.gvsig.com