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

Fri Mar 26 20:15:55 CET 2010

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

On 26/03/10 19:17, Benjamin Ducke wrote:
> 
> ----- "José Antonio Canalejo Alonso" <jacanalejo at yahoo.es> wrote:
> 
> Hi Jose,
> 
>> Hello Ben,
>> there are a lot of people working on gvSIG Project and trying to make
>> it sustainable for the future. That's not easy but they make it
>> possible.
> 
> Yes, I understand. I am one of them. I have dedicated a lot of time
> to gvSIG because I am convinced that it is a great project (and has
> some equally great developers and users, btw.) and I believe that it is the 
> first time an open source GIS is getting close to breaking the ESRI monopoly.
> 
> That's why I feel it is important to talk about anything that may be
> going wrong!
> 
>> Your sentence is not true: "we have an official version for use at CIT
>> and branches for use by the rest of the world" . The official version
>> of gvSIG is for use all over the world.
> 
> My expression was probably a bit drastic. What I meant to say was:
> A lot of users are expecting gvSIG to run on Java 1.6, to include
> SEXANTE, to run on Win7 and Mac OS X. When these demands are not
> being met, even though it is technically possible to do so, users
> start wondering "why?". If the answer to that question is: "Because
> of some internal consideration at CIT", then that is likely to frustrate
> people outside CIT. I think we can see this start happening now and
> it is not a good thing...
> 
> Also, the way gvSIG is being developed very much to fit CIT workflows
> increases the risk that users with very different data and workflows
> will get into trouble. An example of this happened to us at OA 
> (problems with the raster engine and affinely transformed rasters) and
> was the reason why we had to fork off the code for gvSIG OADE 2010.
> 
>> How do you want to make gvSIG OADE sustainable for the future us an
>> open source project in the true spirit of it?
>>
> 
> I have worked in other open source projects before this one and
> had a chance to study some of the dynamics involved, so let me
> share some of my experience with you.
> 
> From my point of view, these are the most important things that
> need "fixing" (a lot of overlap with Silvio's last message):
> 
> 1. Publish an up-to-date and complete roadmap. So everyone can
> see where gvSIG is going (and be ready to make adjustments if
> there are good reasons being voiced by the community).
> 

I agree, maybe we tried to have a so much detailed roadmap that was
not sustainable. I simple approach will be, in my opinion, more useful
for all, the ones who have to maintain it and the ones who need them.

> 2. Complete English translations and communication (all web pages, 
> all documentation, all traffic on the bug tracking list,
> source code comments, error messages and GUI strings). Otherwise
> this project will remain largely closed to non-English speaking
> code contributors.

We are working on that, gvSIG user docs are more or less all in
English right now, except some JCRS docs.

All the new bug reports are being filled in English, and the new code
comments too.

The lacking English GUI strings will be easily detected and will be
marked as a bug. That task was not easy with more than 4600 strings. A
this time 89% of gvSIG is translated, and 524 remain untranslated.
Take a look at:

https://gvsig.org/web/projects/gvsig-desktop/gvsig_desktop_i18nstorefolder/gvsig-desktop-i18n/TRACatalogoInforme/

This report is part of the new i18n web app to maintain the huge
number of strings in gvSIG and in fact is also a free software project
for the Plone CMS

http://forge.osor.eu/projects/gvsig-i18n/

Regarding the source code, the new code will be documented in English,
at least the public APIs. But, yes, there are a lot of javadocs in
Spanish. If you need help on any, ask here and someone will help you.

> 
> 3. Open up discussion of new features and design. Let your users
> share their thoughts about how to get features "just right". 
> It will give interesting perspectives and improve quality all over.
> 

I agree also, we've talked so many times regarding to have some kind
of structurated place for new feature request... Soon we will have all
our tickets on OSOR and there will be a tracker for feature requests
available.

http://forge.osor.eu/tracker/?group_id=89

But remember someone has to develop them, even more, has to be paid
for it!!

So before blaming any of the gvSIG promoters remember that gvSIG is so
good or so bad because of their envision and commitment with free
geomatics. Maybe sometimes is not aligned with others ideas or
principles, but they've always been "bona fide", believe me.

> 4. Open up the bug tracker read-only for everyone, but also
> give ticket writing privileges to those users who would like
> to go bug hunting and file reports directly. Urgent: switch
> all communication on the bug tracker to English as soon as
> possible. Essentially, this means external peer review 
> -> huge quality booster!

Well in fact is at this time public, but as we are migrating it to
OSOR, we didn't publish it to create more confusion.

https://gvsig.org/trac/bugtracking/report

> 
> 5. And finally, most importantly: release early, release often!
> Don't worry about every release being perfect or even able to
> run at all. People can always switch back to an earlier version. 
> But do give plain users a chance to try even small improvements 
> and provide feedback on how a major release is shaping up. 
> This actually was done quite well on the way up to gvSIG 1.9 
> which sometimes had a release every week (Ideal! Please let's 
> have weekly builds again!), but somehow no longer happens. 
> Note: this would also need to be done for extensions!
> All we need is an automatic snapshot of the SVN binaries once
> on a Friday evening.

I wrote about this on my last mail, so yes, we want to do it, with a
six month release plan, some releases won't have all the features,
other will have. The weekly builds are an effort on stabilization
process, as they are right now, are not possible because the consumes
a lot of resources.

BUT, we are reaching the place were automatic builds will be possible,
so the classical "nightly builds" in any form will appear, Fran has
been doing some tests with Hudson to achieve it.

> 
> Along the lines of what Silvio said: Some things to ponder over the weekend!
> 

Sure!!

- -- 
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/

iQEcBAEBAgAGBQJLrQfqAAoJEAOYD75lvHdBQBoH/14CummKWxKiHCh6kcDrnzFY
peEbFvIrLnnW7EIqj5lg0Ge5J1I92COqfapgUWdoDC0MhJ7u/C0EkogmCUPa54X9
wPcKWXvlHcBNNNA3rl7+XAUFG2ZJ8OO84/uIBpTOiGklIPIN+QT7hkUJ45Saf6mr
1uWq3FtUf6lUZHt7/TM6wxL4jpv2VqQFoVJpOVvQIvpQoP41bWgqavl68vzllaV4
UZPg5GKNLki3rA/EUcAGjVtAHU4Ow3eFoOsjGHay8nAjcMrKZAGPkAzAQNBA8I7b
J3GwE3lkelTBIJu4bj7PytnyFpgzQ9SOYdLR0duIVZPyA2YhufFKs4Pi7Wa5hAE=
=V4Ge
-----END PGP SIGNATURE-----