Jose I understand that branching is not exactly a popular move and rightly so: it wastes time and resources and creates unnecessary confusion for users. But at the time I decided to make the OADE branch, there was no better choice. The reasons are ultimately linked to the release policies of gvSIG 1.9 and 2.0. Let me give you some history on the process. Maybe you will understand my reasoning (and maybe even sympathize with it).
The branching was done under high time pressure because OA needed a reliable interactive open source GIS to replace ArcMap as a desktop client ASAP. We were pushing hard for the acceptance of an open source GIS solution and for that we needed a software that was feature-complete and stable enough for production work. Version 1.9 looked like it would be exactly what we needed, but at some point during the bug fixing phase (to which I dedicated a lot of time and filed many, many bug tickets), with many bugs still open, it was decided to release 1.9 and move all development resources to 2.0. As much as I understand the reasons behind this move from a technical perspective, it was very frustrating for us. The official gvSIG version 1.9 was not in a state to be fit for production use at OA. The binaries did not run on newer Windows versions, there was no Mac OS X support and SEXTANTE no longer worked. And nobody else seemed to be actively working on 1.9 anymore. This left users (not only ours) in a really, really bad spot. Let me repeat this: 1.9 was declared OFFICIALLY DEAD CODE. So what choices did we have? Contribute to a dead project? How? Or wait for 2.0 to come around at some point in the future? That was out of the question, as we needed a solution fast. NOW there is talk of a 1.9.1 version, but that started when I was already working on gvSIG OADE Beta 2. Had I known that 1.9.1 was planned, I would NOT have done the branching. But these decisions are made on internal project meetings at CIT, so I got to know about them too late... So I polished up my Java skills, started analyzing the gvSIG source code and picked up what everyone else seemed to have just left behind. I added a lot of bug fixes, improved the GUI and released the software. At the time, it really looked like nobody else would do the job, so I just did it myself! Let me make this clear again: I did not start a separate code branch because I think it's fun, but because at that time to me it seemed the only way to get out a production ready version of gvSIG 1.9 -- and fast. There is no bug tracker etc. for gvSIG OADE because I do not intend to keep the branch for long, so it would be a waste of time and resources to put up all that infrastructure. Again: come version 2.0, I want to integrate all this work back into the official gvSIG code tree. HOWEVER, I have sent each and every modification I made, all new interface strings and every single bit of my code including a complete and detailed log to the main developers. I have done that since the very first changes I have made and I will continue doing so! I have also filed bug reports along with the code necessary for the fixing for every single bug I fixed. With all this, I have been actively contributing to gvSIG (the official gvSIG) at least as much as I have been working on the OADE version. But I only recently got write access to SVN. So until now, it was up to the main developers to include my modifications -- or not. And this is the situation now: 1. It has been decided that gvSIG 1.9.1 will be released. 2. I have been granted write access to SVN. 3. GvSIG OADE 2010 has been very popular with users around the world and the final version is almost ready for release. 4. There is no final time schedule for gvSIG 2.0. So the question I am now pondering is: where do we go from here? This is merely a question of efficiency, not whether or not I am willing to contribute back to the official gvSIG project. Best, Ben P.S.: So far, users seem to be pretty happy about about having a version that runs on Win7, includes Java 1.6 and SEXTANTE. At OA, we work very hard to advocate gvSIG and the OADE branch has done a lot for increasing the acceptance of open source GIS in the English-speaking world. ----- "José Antonio Canalejo Alonso" <[email protected]> wrote: > Yes, it is easier to integrate external developers' contributions into > a "live" codebase. > Bug fixing and extensions are easier to add in a "live" codebase if we > don't have branches. > I don't understand why have you made the branch gvSIG OADE. gvSIG OADE > is today gvSIG 1.9 with some gvSIG extension bundled, Complete and > consistent English (GB, US) GUI translation, ... Where is a roadmap of > gvSIG OADE? Where is the gvSIG OADE bug tracker? Etc, etc. > You took gvSIG 1.9 and made a better English translations and > communication but without gvSIG you can not go on. It makes more sense > to put this work on the original version of gvSIG and try to work > together. Is your Complete English translations and communication in > gvSIG 1.9? We are working to have a 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) in gvSIG Project but without a branch because is easier and > more sustainable for the future to work directly with gvSIG Team. > Maybe you can explain us the reasons you had to decide to make a > branch and how do you want to make it sustainable. I think we confuse > the users with this kind of branch. > > Cheers > Jose > > > -- > José Antonio Canalejo Alonso > CSGIS > Email:[email protected] > Web: http://www.csgis.de > > > > > > De: Benjamin Ducke <[email protected]> > Para: Users and Developers mailing list > <[email protected]> > Enviado: sáb,27 marzo, 2010 15:49 > Asunto: Re: [Gvsig_english] gvSIG project structure > > Hi Jose > > this would be just a temporary solution for work based on the > "dead" 1.9 codebase. Hopefully, somewhere along the 2.X line > we will be able to merge everything back into one codebase > and there will be no more need for any branching. > It will be much easier to integrate external developers' > contributions into a "live" codebase. > > Also, as far as bug fixing and extensions are concerned, > there is no problem and no need for any branches. > > Cheers, > > Ben > > ----- "José Antonio Canalejo Alonso" < [email protected] > schrieb: > > > Hello Ben, > > working together but keep an OADE branch?? I can't understand that. > > What kind of "working together" is that? Without gvSIG is not > possible > > to have gvSIG OADE. > > gvSIG needs to have a larger number of external contributors working > > together on the same project but not in different ones. There are > now > > several external contributors working on the same project: gvSIG . > Why > > should it be different with OADE? This approach seems not to be > right > > :( > > Regards > > Jose > > > > > > -- > > José Antonio Canalejo Alonso > > CSGIS > > Email: [email protected] > > Web: http://www.csgis.de > > > > > > > > > > > > De: Benjamin Ducke < [email protected] > > > Para: Users and Developers mailing list > > < [email protected] > > > Enviado: sáb,27 marzo, 2010 12:56 > > Asunto: [Gvsig_english] gvSIG project structure > > > > > > ----- "Luis W. Sevilla" < [email protected] > schrieb: > > > > > Hi Ben, Jorge (community), > > > I have null interest in perform or participate in a flame war. > > > > I think we can all agree on that! > > > > [SNIP] > > > > > point, but an abstract could be: Big changes in project > > > management/driving could be done before gvSIG could be considered > an > > > open project. It's free software, and collaborative. But not open > > > because there's no openness in project decision taking, not > > > transparency. > > > > > > > So maybe for the immediate future, as regards gvSIG and gvSIG > > OADE, one approach would be to work very closely together regarding > > bug fixes, but keep an OADE branch for other changes such as GUI > > design decisions, that are not of critical importance but more a > > matter of "taste" or workflow habits. > > > > I will have to think about some possible options for a while and > > will get back to you with some suggestions in the "gvSIG 1.9.1" > > message thread. > > > > I think in the long term, this closed decision making will have > > to be reconsidered if gvSIG is to attract a larger number of > > external contributors. Eventually, there should be a way for > > anyone with the right skills to become part of the decision > > making group. But that is an issue that can probably wait for > > discussion until the right time comes. > > > > Best wishes, > > > > Ben > > > > > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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
