[Gvsig_english] gvSIG 1.9.1

Mon Mar 29 15:48:48 CEST 2010

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

Well, I sent you guys all the changes I made, with complete
documentation for review. That's all there is in my fork.
If you think the differences are too big, then I can feed
my changes into SVN one by one. I'd like to avoid that as there
are many and I don't know which ones you already have merged
yourselves.

But I will do that if I have to. The most important thing
for me is to find a solution for a sustainable 1.9.x common
code base.

Of course, if it's all too complicated, we can simply continue
as in the past and I will file all my changes as Trac bug tickets
for you to review and merge (or not).

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

But hasn't most of that work been done for 1.9? Is 1.9.1 not just planned
to be a bug fix release? A minor update? Or am I getting something wrong?

> There's also a hard work to do when you add new features or you change
> the GUI: documentation. Who would do these changes?
> 

Yes, that's a problem. But that's a problem with extensible systems like
gvSIG by design: depending on which extensions are enabled, the menus may 
look different. Also, many menu items in gvSIG 1.9 have overlapping menu 
positions, so they (and the icons on the icon bar) get a little bit "shuffled",
depending on loading order at every startup.

I have never seen a GUI-driven software where the documentation screen shots
did not lag a little behind development after a while. I think we can relax
about this and assume that users will be clever enough to tolerate small
discrepancies.

Besides introducing consistent keyboard shortcuts, divider lines in the
main drop-down menu and fixing the order in which menu items are loaded,
I really didn't change much about the GUI.

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

I think I have probably spent about that much time on testing since
starting to work on the 1.9 code base.

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

OK.

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

Yes, BitRock InstallBuilder is a problem at the moment, as it is not
open source. I looked at InstallJammer, too. Unfortunately, last time
I checked there was no Mac OS X version. Has that changed now?

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

Coming from completely open projects, such as GRASS GIS, I am probably
used to a very different style of collaboration. There was no hierarchy
and no distinction between "external" and "internal" developers, nor such
highly articulated procedures. Everything just grows "organically" in these
projects.

I am just now learning 
Please have a little patience with me. I am sure I'll figure out the
"proper style" very soon ;)

I never really intended for OADE to become a code fork. It started out
as a more conveniently packaged distribution, then when there was no
more life in 1.9 and it was not ready for production use at OA, I
decided to change some code myself, had a lot of fun doing that,
et voila -> gvSIG 2010 OADE.

I never expected it would get political!

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

Yes, of course!

As I proposed before, a good compromise may be for
me to first feed all my changes that relate to bug fixes into SVN. Those
are not too many and they are well tested (by me, at least).

Then there is a much bigger set of changes that relate to GUI changes
and other "matters of taste" (e.g. a large patch to unify filetype
names in all gvSIG file selector windows, some additional items for
the context menu, etc.). 
How about you merge these (they really don't affect that much code and are 
completely documented) yourself if you like them? That would leave me with 
some time for additional bug fixing.

As regards the changes in menu structure (you know, all those config.xml)
files: those can be regarded a form of "skinning". We will provide them
in a separate download archive on oadigital.net. Then people can install
them seperately on top of any version of gvSIG they like.

Best,

Ben

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