[Gvsig_english] QUESTION gvSIG 1.9 (BN 1253) -- Future of gvSIG and Sextante

[Jorge Gaspar Sanz Salinas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben and all let me answer your firt email and I'll continue discussion
in next messages.


On 26/03/10 10:23, Benjamin Ducke wrote:
> Hi Simon,
> 
> All valid questions and I am sure they have been on several
> people's minds, so I will try and answer them (as far as I
> can) in some detail.
> 
> ----- "Simon Cropper" <scropper at botanicusaustralia.com.au> schrieb:
> 
>> Hi,
>>
>> A recent post by Victor outlined the roadmap for Sextante.
>>
>> In it he indicated he intended to make Sextante into a library and
>> allow various developers to assimilate this library into their
>> projects, rather than maintain a plug-in system which requires
>> constant rejigging to ensure the bindings work.
>>
> 
> Yes. This was at least in part motivated so that SEXTANTE could
> move on to use more recent versions of Java and stop wasting a
> lot of time worrying about backward compatibility.
> 
>> Surprisingly, despite Victor pointing everyone to OADE 2010, the
>> developers of gvSIG (core project) were not goaded into a response.
>>
>> So I am asking... What is the position of the gvSIG Developers
>> regarding Sextante (you have had enough time to talk about this)? Are
>> you planning to incorporate the upcoming library into gvSIG or will
>> you let this plug-in languish? I suppose the question is also relevant
>> for the next version of OADE.
>>
> 
> As far as OADE is concerned, we have decided, after some deliberation
> with Victor, to synchronize the release cycles of SEXTANTE and gvSIG OADE. 
> So the final release of gvSIG OADE 2010 will come with SEXTANTE 0.6 as part 
> of it. This is possible, because gvSIG OADE already runs fully on Java 1.6.
> 
>> I think this is an important question as Sextante elevates gvSIG into
>> a product that can be used in a production environment; without it
>> gvSIG lacks important basic functionality.
>>
>> And at a personal level, I am in the final stages of preparing my
>> templates for my how-to manuals -- should I be writing my
>> documentation for OADE 2010 (which incorporates Sextante) or
>> gvSIG+Sextante or if the use of Sextante is uncertain, other upcoming
>> packages? I am also on record stating that gvSIG+Sextante is the first
>> FOSS GIS that I could use in a production environment. There is also
>> an upcoming paper in OSGeo Journal to that elk. So, will these
>> statements hold true in the future or will the gvSIG product fall back
>> to just the core modules?
>>
> 
> I can sense some (warranted) frustration here. Indeed, the CIT gvSIG release
> policy, as much sense as it makes sense from an inside point of view,
> has violated one of the basic, "outside" rules of open source commitment:
> release early, release OFTEN. As the CIT developers are now focused on
> making gvSIG 2.0, the open source user community is faced with the
> following, bad situation:

Well publishing a new release of gvSIG is huge task, maybe too big.
But we stablished a hard process of stabilization and starting it is
not as easy as it would be. We expect to change that, and we've been
talking about doing 6 months releases, but this will have drawbacks
like regression of features from one version to the next.

I hope this half-a-year release plan will be ready for 2.0 and next
releases.


> 
> 1) The last release (1.9) with full functionality is not production use
> ready as it contains too many critical bugs and no longer runs the
> latest SEXTANTE.
> 


Yes, at this time the official release of SEXTANTE is not working on
official release of gvSIG 1.9 like many others libraries. Sometimes
it's impossible to have all the libraries updated on the official
versions of a software, as it's hard to assure stability.

The same applies with the java virtual machine version. Of course is a
must to be as updated as we can, but it consumes a lot of resources on
development and testing teams.

I can assure you and all that we are doing our best to have all this
mess with SEXTANTE distribution solved as soon as possible, nobody
wants a regression of features on gvSIG.


> 2) The current code (2.0) has not yet been released as up-to-date
> binaries. And even when that happens, it is not clear how many of
> the extensions (not just SEXTANTE) will have to be updated to run on
> it and how long that is going to take.
> 

Sextante will be on 2.0. The migration is a work in progress, and it
will be on the most updated version. I can't assure 100% that will be
in 1.9.1, or whatever name it will have, but obviously this confussing
situation has to be solved ASAP.


> So in between, there is a big gap for a release that's bug-free enough
> for production use, runs SEXTANTE and includes all the other current
> extensions.
> 
> This gap is where gvSIG OADE 2010 currently thrives!
> 

It's great thing that the OA team solves bugs on gvSIG!! Hopefully
most of your work will revert on the gvSIG, as soon as possible.

On the other hand, the link to the modifications you made to gvSIG is
not working

http://88.208.250.116/gvsig-oade-mods-1.0.0.tar.gz

One example: the nice en_GB and en_US strings improvements are being
included on the new i18n web app. So the will be available to all
users on the next release of gvSIG.

I want to note here that you say you are on beta phase. So, witch
changes or bugs are you planning to resolve on your final, stable
version? Why not to resolve them on the main gvSIG code base?


> But bug fixes and SEXTANTE were not the only reasons why we made the 
> decision to finally branch off gvSIG OADE 2010. We were also dissatisfied 
> with some aspects of the user interface and with how some basic things,
> such as raster table legends, are handled.
> 
> Since the development directions of gvSIG 2.0 are not exactly
> transparent (e.g. there was talk about a new way to handle external
> table joins on this list, but no details on how that new design
> looks), and gvSIG 1.9 was officially declared an abandonded code
> base (this has now changed with the chance of a 1.9.1 release), we
> eventually saw no choice but to branch. We have a growing production
> user base for gvSIG in our company and we owe it to them that they
> get frequent, stable releases of the software to work with.
> 

The development of gvSIG 2.0 is pretty transparent in my opinion. All
the sources are on the SVN repo, and any question asked here is
answered by the developers and architects. You can just do in your
console

svn log http://subversion.gvsig.org/gvSIG/branches/v2_0_0_prep/

and see in real time the changes on gvSIG 2.0 code base.

Yes, the technical docuemntation is at this time in Spanish, but it's
planned to translate it. All the help we can get from the community
will be more than welcomed as the amount of documentation is really big.

https://gvsig.org/web/projects/gvsig-desktop/docs/devel


> We did not take this path light-heartedly. Branching off of the main
> project is a very problematic move in open source development with
> the potential to both waste a lot of resources and split the
> community (both users and developers) -- some of the effects you
> are experiencing right now!
> 

Yes, from gvSIG project side we are going to do all our best to
collaborate with anyone willing to, it would be a pity if you finally
fork gvSIG.


> So we really, REALLY hope that the 2.0 code line will allow us to
> re-integrate all the work that has been done here at OA and not
> force us to maintain our own branch any longer.
> 

Why to wait to 2.0? Why not just try to integrate that changes now. I
don't have any problem with custom distributions of gvSIG, it's normal
on free software, but it's not the same to do a new distribution using
a privative installer, a new splash, and some nice documents than
doing a real fork.


> There are good indications that this will be possible, but only
> if the development of new features and GUI designs gets more
> democratic.


Well the development of new features is managed depending on the funds
or contributions the gvSIG project receive (as any other free software
project). This is not democratic, it depends on the funding entity
strategy. At this time, the main funding organization to gvSIG is CIT
so the new features of gvSIG are driven by this organization like the
new developments on sensors and topography. Of course these mailing
lists are a way to promote new features and recommendations, they are
not a black hole as someone said once.

On the other hand, the gvSIG project has a technical steering
committee where technical decisions are made, you can read more about
it at at OSGeo wiki[1]. This info will be on the gvSIG portal site,
but it's being refactored and we placed this info on the OSGeo wiki on
the meantime. I'm the "chair" or "manager" of this committee so don't
hesitate to ask any question you have and I'll do my best to try to
answer.

We're formalizing a way to contribute new developments to the project
so if OA wants to develop a new extension or something, it will be
possible to include it on the official version of the project. For
example, NavTable will be part of the gvSIG official distribution.

We also lack a more openness on working teams that the project have,
like the one for usability, but it's a trend on the project to open
more and more its procedures, committees and policies. This is also a
huge time consuming task, but in my opinion a major duty with you, the
community. I hope over this year a lot of this info will be public.

> 
> This whole thing is a learning experience for everyone involved.
> If you look at the history of other big projects that went open source,
> such as Mozilla or Star Office, you will realize that there were always
> problems like these in the start-up phase.

Well gvSIG is a +5 years old project, we're not on an start-up phase.
Maybe we're on a phase where we are talking more about government and
policies but gvSIG is not a newcomer to nothing.


> 
> I suggest, that BEFORE the 2.0 release, we have an open discussion on
> this mailing list to rectify things. The 2.0 release is the big chance
> to get it all right. Let's not blow it.
> 

Well this is happening right now, thank you very mutch to open up this
thread, really.

Cheers
Jorge



[1] http://wiki.osgeo.org/wiki/GvSIG_Technical_Steering_Committee
- -- 
Jorge Gaspar Sanz Salinas
gvSIG Team
Tehcnical Steering Committe Manager
http://www.gvsig.org
http://www.gvsig.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLrQBAAAoJEAOYD75lvHdBvx4H/RobXGkWpd79tPQ+Obp/Yxzn
lvo0CkXx+k2goDPrvwZ2zg2R1mO3ieY5W9GtwvQdCrM4vXp53pRJHBc/xoGMgu1D
TEhTM/4w1CflowcTSCFc9KzKjPOVSWBvh+XJhIJQ2iAjdmIwO+AXaaNsyGb0hQnX
ck8oyT5D/l3oVpRgs084gKCecZic9hYWmSXB6iS3np1Hkm6fAnIw5iWR4BEiew8k
tU1NJbPpQkMxQI0sBpnPP0CiGVG8B1nTOy/bTeRrsSZtwaPyQV9snUMjVbpyPs+x
HtTweX4ZXXRXBqb6wQBFYWNUECyh7LlxDzehsF9fdpW+SgBj/tDWOMN5yU9aoA4=
=4Cia
-----END PGP SIGNATURE-----