[GRASS5] Suggested color function names

Glynn Clements glynn at gclements.plus.com
Mon Apr 24 12:44:39 EDT 2006

Markus Neteler wrote:

> > Alpha support in the current display architecture isn't going to
> > happen (I reverted the last attempt to add it, and will do likewise in
> > future).
> ... this is why I really suggest to get interested in a project
> steering committee [1], [2].
> Instead of recursively reverted changes of other developers,
> we should come up with a design discussion and then *vote* on it.

Who gets to vote? Anyone who wants to, only people who contribute
code, only people who will be affected by the decision, ...?

E.g. with a display architecture, the risk is that "application"
developers would vote for the ultimate graphics API which includes
everything provided by both OpenGL and PostScript and then some
extras, which consequently never gets implemented.

> At least for such crucidal pieces of the code I would like to 
> see less anarchy and a more formal approach.

I'd certainly agree with the "less anarchy" part, although I'm not
sure that a "committee" is the answer. The mailing list is a perfectly
suitable forum; people just need to use it (the first thing anyone
heard about the alpha "enhancement" was a message informing everyone
that it had been committed).

A simpler solution would be to have defined maintainers for specific
sections of the code base. Developers would be expected to discuss any
non-trivial changes to another developer's section beforehand. 
Maintainers would have more liberty to act within their own section,
but would still be expected to discuss more substantial changes,
particularly if the changes would be "visible" to users or other
developers (as opposed to purely internal changes such as refactoring
or optimisation).

> This will render
> development more transparent to everybody. The scope cannot be to
> have two display management systems in parallel, one without
> and one with alpha support.

We already have both the historical display architecture and ps.map. 
Also, while gis.m is based on the historical display architecture, the
end result is sufficiently different to effectively be a third

Glynn Clements <glynn at gclements.plus.com>

More information about the grass-dev mailing list