[Gvsig_english] gvSIG 1.9.1

[Miguel Montesinos]

Hi Chris,

>De: gvsig_internacional-bounces at listserv.gva.es en nombre de Chris Puttick
>Enviado el: lun 29/03/2010 15:27
>Para: Users and Developers mailing list
>Asunto: Re: [Gvsig_english] gvSIG 1.9.1
>

>


>----- "Miguel Montesinos" <mmontesinos at prodevelop.es> wrote:
>
>> Hi Ben,
>>
>> I'm not going into the origin of your fork decission. I'm sure *both*
>> gvSIG and OA have made some communication mistakes. A direct
>> communication would have avoided forks and time and resource wasting.
>> For sure at gvSIG we are pushing forward for external developers to
>> come in the project and join us.
>>
>> Looking only at the future side, I encourage you to work together with
>> gvSIG people.
>>
>> >   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!
>>
>> It makes sense if we skip the stabilization process. The problem is:
>> Do we skip it? If so, can we call it a stable version? If not, who is
>> going to perform the stabilization process?
>>
>> Maybe the stabilization process is not important for you, because you
>> have fixed those bugs, but for some organizations it's important, as
>> they cannot rely on a beta or unofficial version.
>>
>> Would OA afford a stabilization process? If so, from gvSIG we can help
>> to teach how to do it.
>
>What do you mean by a stabilisation process? Is the same sort of process that Microsoft et al would go through before releasing a product?

I refer you to Jorge G. Sanz's mail to this same list, just a few minutes before your post. Surely you were writing your message when Jorge's one was sending his.

>
>
>Does it result in a bug-free product?

 

Not at all. Software is never a bug-free product. It's just a question of trying to minimize bugs when you have almost 2 million lines of code. It's a fact that gvSIG does not achieve it completely, but our intention is to optimize quality, and IMHO sw quality needs a stabilization process. For sure our stabilization process can be improved, so we are glad to get new inputs.

> What sort of organisations believe that a beta/unofficial version of a product is inherently less stable/usable/bug-free than an official non-beta official release? I have to ask, albeit "tongue in cheek", because there's a long history in IT of there being no connection between the stability/bug-count of a product that has been officially released v. ones that stay in beta.

If so, why don't people just release their beta versions? An official version is not bug-free, but I'm sure you're pulling my leg if you try to sell out that beta versions are the same than official versions. I know several public administrations (for instance) that wouldn't allow an unstable version to be deployed over hundreds of thousands of clients.

>A stable product is one to which no changes are being made. A stable application is one that doesn't crash in normal use.

A stable product is one that the project team considers with a level of quality good enough to be released, with no critical (or the desired bug level) bugs. Of course it shouldn't crash.

> We needed certain features functioning in gvSIG as soon as possible to make it usable in production, and in a way that made end-user installation very simple. This is why Ben was able to spend so much of his time making the OADE versions of gvSIG.

I understand your requirements. We'd just like to see Ben working close to our developers in the same repo and so on. I assure that our developers also spend a lot of time working on gvSIG. Don't duplicate efforts is what I'm trying to communnicate.

> I fully understand that the core of gvSIG development has specific sponsors with specific needs, and that those needs have to be met. Our needs are different and a degree of urgency is one of them, hence gvSIG OADE. Maybe this discussion should be taken off-line; I would be happy to discuss at length with both the core team and the sponsors the non-technical reasons why gvSIG OADE had to exist and my views on the basis for successful open source development (which are broadly in line with Karl Fogel's http://www.amazon.com/Producing-Open-Source-Software-Successful/dp/0596007590 ).

I know Karl Fogel's book, as well as some members of gvSIG do. We are open to further discussions, and we would like to have them in order to avoid actual gvSIG problems, but I disagree it should be made in a closed way. Weren't you asking for transparency? Let the community be aware of our oppinions. Be sure that gvSIG will allways embrace contributors and collaborations from the community, we'd like to have more and more, so please use this public space to let others know what's going on and give their oppinions.

So, please feel free to express your non-technical reasons why gvSIG OADE should keep existing as a ¿distribution/fork? and share your basis for succesful open source development.

>Regards
>
>Chris
>
>--
>Chris Puttick
>CIO
>Oxford Archaeology: Exploring the Human Journey
>Direct: +44 (0)1865 980 718
>Switchboard: +44 (0)1865 263 800
>Mobile: +44 (0)7908 997 146
>http://thehumanjourney.net <http://thehumanjourney.net/> 
>
>
>------
--------------------------------------------

Miguel Montesinos
CTO
Prodevelop
Tel: +34 963510612
http://www.prodevelop.es 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 7872 bytes
Desc: not available
Url : http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20100329/65ed1bde/attachment.bin