[Gvsig_english] Call for Mac Community contributors.

[Jorge Gaspar Sanz Salinas]

Hi Jordi,

El mar, 24-05-2011 a las 17:04 +0200, Jordi Torres escribió:
> Hi Manuel, 
> 
>         Well, I talked about this in the last TSC Board meeting and
>         maybe we
>         should discuss some points before creating a new Osor project.
>  
>         1. SVN. Since gvSIG for Mac and the rest of gvSIG
>         distributions share
>         the 99% ¿why not use the gvSIG repository?
> 
> No problem for me. But we need full permissions to branch some
> projects in the gvSIG svn, and of course commit access to the members
> of the working group. If a new project in osor is created, only the
> projects changed shoud be committed, not the whole gvSIG. 


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.

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?

We think that this way, and having all the Mac specific code at another
OSOR project is the most sensible approach.


>         2. Bugtracker. Issues should be managed in the place (project)
>         where the
>         source code is, so I think it depends on the 1st point.
> 
> I agree, but it must be clear that the bugs uploaded to this project
> (both in osor or as a gvSIG subproject) have to be related only to
> MacOSX distribution. 
> 


You know, gvSIG bug tickets have an operating system field, so there's
no problem to clearly identify the Mac tickets.


> 
>         3. Binaries. Well, this is not a critical issue. Maybe it's
>         more
>         confortable to use a specific Osor project instead of the
>         official one.
>         
> 
> So you rather to create a new project or use the gvSIG-desktop project
> (I guess creating a subproject)?   


If you finally have an OSOR project for your specific developments,
having there binaries should be OK but we can discuss that in the
future.


>         4. Wiki. Of course a colaborative project needs a place to
>         share
>         whatever documentation. Currently the gvSIG project web
>         (plone) has a
>         section called "Collaborations" that could fit. A second
>         option could be
>         a wiki in the new Osor project.
>         
> 
> I prefer to use osor for the wiki, I don't feel very confortable with
> plone, but is a personal opinion. 
> Finally, and again in my opinion, it will be more agile if we own a
> new project in osor, but I am open to work anywhere. 


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.

This is the way a lot of projects are moving their documentation systems
(mapserver, geoserver, mapproxy, etc.) and you maintain the markup so
uploading the documents in the future to the gvSIG portal would be
easier.

For the georesources project we did that[2][3] until we had the portal
space and moving the docs was quick and easy[4].

Best regards

[1] http://sphinx.pocoo.org/
[2] http://georesources.forge.osor.eu/doc/
[3] https://svn.forge.osor.eu/svn/georesources/trunk/doc/
[4] http://www.gvsig.org/web/projects/contrib/geoResources/pub

-- 
Jorge Gaspar Sanz Salinas
gvSIG Team at Prodevelop
Technical Collaborations Manager 
http://www.gvsig.org
http://www.gvsig.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20110526/a6f2884d/attachment.pgp