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" <[email protected]> To: "Users and Developers mailing list" <[email protected]> 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" <[email protected]> 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 > [email protected] > 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 [email protected] 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. _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
