[GRASS5] GRASS development model Was: A private conversation
grass5 at geog.uni-hannover.de
Mon, 19 Feb 2001 12:20:16 +0100
I have read Mr. Sherpard and Markus opinions, and I would like to share
Mr Sherpard looks at GRASS from a strict user view, it uses GRASS as
a product and of course he wants a stable one to make its daily work.
Markus looks at it both as a product and as a development project, and
of course he considers welcomed any new feature that might be of
interest. I agree with Markus that an open source project cannot be
treated like a commercial one, and that it is not advisable to make
only one person to manage changes, for two reasons:
* too many unpaid work for just one person;
* if that person stops coordinating, the project get stucked too.
My only advice for an engineering point of view is: release often,
release stable code, release few changes at a time. From a user
point of view, GRASS 5 needed too much time to get released, and
this is because it introduces too much changes from GRASS 4 ->
nviz, fp raster, new sites format, new xdriver approach, better
portability, etc, etc. I think most of GRASS users are using GRASS
5 beta because they need some new functionality. These users could
be kept on stable releases if GRASS would be released more often,
with minor changes, and maybe Mr. Sherpard had less to complain about.
I know that bug-fixing is not much exciting, but I think feature freeze
and one or two months of bug-fix could be useful. In parallel, the new
version of GRASS could be released, this can be done if the development
team uses cvs branches.
I know that an involvment in GRASS development team would be more
appreciated, but a single advice is what I can afford to give now.
If you want to unsubscribe from GRASS Development Team mailing list write to:
subject 'unsubscribe grass5'