[GRASS-dev] endian & generic library

[Michael Barton]

I would like to humbly mention that the issues below are another reason why
GRASS probably needs something like a PSC and process for formalizing such
decisions now. It has grown from a CERL in-house project to an enormous,
exceedingly complex, wonderfully active, and very powerful geospatial
research tool. A year or so ago, before some code clean up, someone
(Hamish?) noted that GRASS is one of the largest open-source projects in
existence with respect to the size of its code base.

These features that make this such a great project and useful software also
make it increasingly complex to self-mangage in an organized way. We all do
an impressive job of it, but a more structured way of coming to design
decisions would be helpful and will become increasingly important if the
project continues to grow and be dynamic. Maybe we need a fairly loose and
heterarchical kind of organization, but some kind of more formal process
would be helpful to me at least.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Brad Douglas <rez at touchofmadness.com>
> Reply-To: <rez at touchofmadness.com>
> Date: Sat, 20 May 2006 15:02:41 -0700
> To: Hamish <hamish_nospam at yahoo.com>, Glynn Clements
> <glynn at gclements.plus.com>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] endian & generic library
> 
>> Brad:
>>> I believe GRASS should have a similar document that is a bit more
>>> expansive and covering design decisions that affect coding style.  I
>>> think it would cut down on repeat questions.
>> 
>> Can you provide some examples of "design decisions"? Just curious.
> 
> Decisions made in the past that the majority of us who haven't been here
> for the long-haul understand.  Few things have been formalized and there
> probably was no reason to do so early on, but GRASS has grown to such a
> size that warrants formalization to some extent, IMHO.
> 
> Examples?  A weak example is the decision to determine endianess at run
> time.  Or the decision to use lib/gis as a repository for functions
> common to other libraries (memory allocation, etc.), then some of those
> libraries not using lib/gis account of "bloat".
> 
> If some of these things sound trivial, it's probably because I take a
> very user-centric approach.  I try to gear things to make the user
> experience better/easier, perhaps to a fault at times.
> 
> Does this help explain my stance a bit better?
> 
> 
> -- 
> Brad Douglas <rez touchofmadness com>                      KB8UYR
> Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785
> 
>