[Gvsig_english] gvSIG 1.9.1

Sat Mar 27 19:58:09 CET 2010

Dear devs

OK, here is a suggestion for gvSIG 1.9.1.
It may sound radical, but it could be a good
solution for everyone involved. You have all
Sunday to think about it ;-)

So here it goes:

  We just take the current gvSIG OADE 2010 sources,
  fix the remaining 2 or 3 critical bugs and release
  that as gvSIG 1.9.1!

Here are the reasons why I think this would make
sense:

1. The "branching problem" is immediately solved.
We can all work on the same code base towards
1.9.2, 1.9.3 etc. as needed, until a fully functional
gvSIG 2.0 is out.

2. Because this means a production use ready and maintained
(by me alone if I have to) version of 1.9.x would be
available, this would immediately take pressure off
the 2.0 development.

3. At the time of writing, the number of modifications
I have made to the 1.9 sources is probably greater than
the number of modifications from other devs, so it would
be efficient: I only need to merge a few recent SVN
changes from your side, and the new SVN code is ready.

4. GvSIG OADE 2010 Beta 2 is already out and you can
test it to convince yourselves that the changes are
working OK.

5. OA could continue releasing an "OA branded" version
geared towards our archaeological users. This would
include things such as archaeological sample data and
support for Mac OS X (which is common among archaeologists).
We would also keep providing binaries with our customized
installer. You could just add links from the main gvSIG
download page to these installers.

What do you think?

Ben

----- Original Message -----
From: "Luis W. Sevilla" <lsevilla at sigrid.es>
To: "Users and Developers mailing list" <gvsig_internacional at listserv.gva.es>
Sent: Saturday, March 27, 2010 12:29:01 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [Gvsig_english] gvSIG 1.9.1

Hi,
Benjamin Ducke wrote:
> ----- "Luis W. Sevilla" <lsevilla at sigrid.es> schrieb
>> Hi Simon,
>> Simon Cropper wrote:
>>     
> [SNIP]
>   
>>> My frustration stems from the desire to contribute more to the
>>> community effort but finding it's is a bit like shooting at a moving
>>> target. It is very difficult to establish how to address development
>>> of documentation when the current version is considered 'dead' and
>>>       
>> to
>>     
>>> be replaced sometime in the immediate future..
>>>       
>>     IMHO this consideration of 'dead development' was a big mistake.
>> I'm
>> unsure about the origin, bu I never agreed with this  qualification.
>> v1.9 will not have development support ... when 2.0 will be stable,
>> but
>> by now (and probably by almost all this year) 1.9 it's our stable
>> version, the one that the user have, and the one the developers have
>> to
>> do his job. 1.9 may not be the perfection, but as is our present
>> product
>> NEEDS support.
>>
>>     So, this worries about lack of support probably were a
>> misunderstand, as next 1.9.1 release will show.
>>     
>
> Luis,
>
> I completely agree with your assessment of the importance of
> the 1.9 codebase. Like Simon, the "dead code" status of 1.9
> was the main source of my irritations and frustrations.
>
> If 1.9 is going to stay alive and will be actively maintained
> until 2.0, then I will also add some extra
> working days and feed all my recent bug fixes (done for gvSIG
> OADE Beta 1 and 2) directly into SVN. That way, we can make
> sure that there are no differences between the gvSIG "branches"
> in regard to stability.
>   
I don't think this is too much realistic. I'll try to explain my point:
2.0 and stability. Now we have a transition status, in witch we have a 
huge restructuring and rewriting of former code in one development 
branch (2.0), that now a days it's not stable enough to be useful for 
end users, and that does not have a time target (as far as I know). 
It'll need to be declared at least alpha status, and thus some of the 
main changes declared as almost finished to enter in a path of 
stabilization. Meanwhile all the efforts of stabilization in 2.0 will be 
almost useless.
1.9 and 'active maintenance'. As I wrote this is a transition status. 
Main development effort is on 2.0 branch, so 1.9 will receive minor bug 
fixes (due to a lack of manpower). The more resources devoted to 
maintain 1.9, the later 2.0 will be release. In this kind of situation, 
you need to balance interest and of course not to arrive at maximum 
targets in any of both areas.
'official' and OADE distribution differences. I think this will continue 
at  least until main project will develop the capability of releasing as 
frequently as OADE needs. I don't see OADE as a branch, cause main 
changes (JRE 1.6 support, ie) were already in 1.9 code. All changes 
you're doing will be incorporated to next gvSIG 'official' release, an 
this different paces mean (at least for me) differences in stability 
(and at some point, in features)
> But we would have to coordinate this with each other. I have
> a very tight working schedule for the next weeks, so would there
> must be enough time allowed for me to merge all my modifications
> and to fix the last remaining 2 or 3 bugs on my list.
>   
It should be nice. It's an effort your organization and official gvSIG 
driving forces need to make. Requirements are always the problem, and 
rarely a lack of interest.

By the way, I have not say it before, but I'm quite admired about the 
bunch to our project that your 'alternative distribution' effort means. 
Competence it's always a source of improvement motivation, and this 
could mean only good new both for end user and developer community. 
Thanks for being there, thanks for pushing hard, and bravo! for the work 
that you have done. Keep pushing.
> Cheers,
>   
Greetings
    Luis
> Ben
>
>
> ------
> Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
>
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>
> --
> This message was scanned by ESVA and is believed to be clean.
>
>
>   

-- 
Director Técnico / CTO
Sigrid - Grupo Acotelsa
Tel. +34 600 433 808
http://www.stereowebmap.com
http://www.sigrid.es 

The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends. (Ron Avitzur)

_______________________________________________
Gvsig_internacional mailing list
Gvsig_internacional at listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.