[GRASS5] The status of 5.0

[M Lennert]

On 23 Mar 02, at 7:04, Roger Miller wrote:

> On Saturday 23 March 2002 06:28, M Lennert wrote:
> 
> > I think this is exactly the point, and it has to be a conscious decision
> > depending on what are aims are. If we want to target the average Esri user
> > who doesn't want to do much more than displaying a few maps and who
> > doesn't have a computer wiz around, then we should wait to be as bug free
> > as possible (with Glynn's qualification about invisible bugs in mind). But
> > then we probably also have to have working and user-friendly gui and map
> > production modules before releasing anything "stable".
> 
> How about if we just target the user that wants all of the modules to work as 
> documented, and doesn't want surprises in his results?  It probably would be 
> a bad idea to assume that the user is a programmer or has a programmer on 
> staff.  Developers need to reconsider anything that requires a user to write 
> a script or other program to work around an inherent problem.
> 

I completely agree with you on that. The only question is: does that mean we 
don't release until everything is fixed or do we release and tell people about 
the problems we have ?

I'll try to reformulate my (clumsy) first argument: 

I think we have to decide whether 

1) to see Grass as primarily a free software project, which in my eyes entails 
a certain responsibility and awareness on the part of the user in the sense 
that she knows that software development is a neverending process, that 
software is buggy, that this is not a catastrophe, that there are people out 
there to help (Markus mentioned the fast response time to bugs in Grass), 
and that actually the user is a vital resource in the search for these bugs 
(and in defining the direction a project should go into). This does not mean 
we should release software that erases everything on the user's disk, or 
creates more work or hassle than not having it, but it means that we should 
enter into a dialog with the users about the status of the program.

2) to see Grass as a service we provide for a large user base that doesn't 
want to know anything about our development problems and is only 
interested in a final product that should be as close to perfect as possible. In 
that case we should develop a more thorough testing routine which covers as 
much of Grass' functionalities as possible and as many different test cases 
as possible. One approach to this kind of test suite might be to collect all 
data that has made Grass fail and use it to test any new releases.

These are just some simple thoughts in whatis more of a general project 
philosophy debate, but I do have the feeling that this (plus the problem of the 
work load (and necessary discipline) of trying to coordinate branches) is the 
basis of the discussion in this thread.

Moritz