[Gvsig_english] gvSIG 1.9.1

[Jorge Gaspar Sanz Salinas]

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