-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27/03/10 19:58, Benjamin Ducke wrote: > Dear devs >
Hi Ben, all. > 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! > To put things in place: are you proposing to abandon SVN repo in order to use... what?? Honestly, we are not going to abandon our repo, any gvSIG release has to come from our source code base. I suppose you're asking us to do an import of a whole new branch of your fork, aren't you? > 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. > But using the gvSIG repositories, this is a must as I said. > 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. Releasing gvSIG is not a matter of compiling binaries and bundling a distro, there is a working procedure for a release, with a hard work on the developers side while testers do a hard job filling bugs and so on. There's also a hard work to do when you add new features or you change the GUI: documentation. Who would do these changes? As Luis said, putting resources now on releasing 1.9.1 will rest them for the 2.0. So we have to balance the resources (which are of course limited) between both branches. From gvSIG project we will do our best to coordinate new releases if there are anyone working on them. You want to promote a 1.9.1? great we can work together and release it with any other company or entity interested in the release. The same for the next 1.9.x As you know, some time ago we did a private call to companies we thoguht could be interested on pushing a new 1.9.1 release of gvSIG. Oxford Archeology was included in this call. The idea was to coordinate efforts between those interested in order to work efficiently. Probably next calls should be done on this mailing list. You say you'll maintain, as a developer, the release of 1.9.1. I'm not sure if you're realizing what this means. Starting the stabilization of a product is more than compiling and creating a build, because when we put efforts on testing, the resolution of bugs are a priority and usually a high demanding time task. Integrating a new develop to the stable brach means to approach a stabilization process that can be summarized in: - - Set the requirements (new features) that will be integrated. - - Design a test plan that covers the whole new functionalities at least until test case level, taking in account both functional and persistence tests. - - Introduce the test plan into our Test Plan Manager (Salomé-TMF). - - Execute the tests and open the possible bugs in our bug tracker. - - Execute a test campaign designed by the testing team taking in account the impact of the new features over the older ones (regression test). After these tasks the testing team evaluates all the bugs found, sets priorities and coordinates the further stabilization process. It involves an iterative process of: test-fix-release-validate. When the Product Management team thinks the release is stable enough, it releases the RC’s and after a few time, the final version. In the long term, the objective is to have after the publishing effort an stable and well tested application, as well as with a convenient documentation for any professional environment. > > 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. > As I said, an official gvSIG release has to come from the official SVN repo. > 4. GvSIG OADE 2010 Beta 2 is already out and you can > test it to convince yourselves that the changes are > working OK. Do you have a test plan for the changes you made on your version? Have you tested the impact of changing to JVM 1.6 on the whole application? You know, to have a compiling sources doesn't mean you won't have problems in execution time. On which platforms (OSes) have you tested your software? In order to get you some numbers, after asking the testing team, the process of testing a possible new 1.9.1 version consumes 200 hours of a well trained tester. A half is for regression tests, I mean, testing the general features of gvSIG in order to detect problems introduced on this new release and the other half is aimed to test new features included on that release. > 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. > gvSIG has a contributions catalog* for non-official software. This catalog is being used by many contributors. You can place there any new distribution you make. * https://gvsig.org/plugins/downloads/ About the installer. gvSIG uses at this time a different installer than OA version (izPack). The installer from OA is not free software. We are going to use a different installer (called install jammer*) for 2.0 but for 1.9 releases we will continue with izPack. * http://www.installjammer.com/ An official version of gvSIG will always be released with a free installer, but of course, OA is free to release its version with whatever installer they want. We promote free software and releasing with a free software installer enables anyone to reuse our work. The main reason to release using a free software is that this way we let anyone to do their own installer with a documented procedure from the project. The OA installer (BitRock) was discarded some time ago because it's a privative software, and it don't let you use it in a commercial product without getting a "professional" paid license*. * http://installbuilder.bitrock.com/compare-installbuilder-editions.html > What do you think? > We work to create a common space with as much actors as we can, but with clear and sensible procedures. We cannot give an ad-hoc response to any particular situation, without taking in account the scalabilty and sustainability of the project. In my opinion, let me say that doing a fork and waiting from the project to accept all the changes you made on gvSIG is at least naive. Do yo imagine that other companies doing the same and coming some months next to any release with their own forks and waiting from us a warm welcome? It's a matter of all of us to have a 1.9.1 release. Do you see any chance to work together with the procedure we've exposed to have it? Cheers - -- 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/ iQEcBAEBAgAGBQJLsKYNAAoJEAOYD75lvHdBxEIIAJfFCbRru59/6sNcdDyOZMdN XRf7TIDUgDsf28/f+VXhNEODXgBe4hNC7vJpju++JLrgdmDuniSFPPo/8kkCO0We VD5XfoKvWOin3ZUaHvNFRVNTe/vkwQc4Zpwab+p++rVRfHYR/HdzdQQY4vj3hOCh k1in+x+d4Jx82uiPe1QZWwv2Be1Yij6dZacB3dew07EuYnd6V7ZXv977g7ZjFQQc aCrHrmulHilCSW+tRuQQFjN8rtjrnRXXPIBixC4xu5ZrhX6OMhjqBoQtK4zNtaJL oc4gO8z1rLjT3Ho6kX+ECGf9z7tCUC2eR0EvqyoZltP6FDGhCM+YPhOiLIbU+Sw= =gYb8 -----END PGP SIGNATURE----- _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
