[GRASS5] Proposal: RFC 1: Project Steering Committee Guidelines

[Glynn Clements]

Markus Neteler wrote:

> I assume that it depends. For example, the design of a new raster
> library should be written into a single document. So far I could
> check various emails on this topic in the email list archives which
> isn't the right approach for changing an important subsystem in
> GRASS. Here I would like to see a single document being worked on
> (often called RFC).
> 
> I know that this is not culture in the GRASS community, but I would
> not mind to see this for *big* changes. Why is it such a big problem
> to draft a document on high impact software changes? It is the only
> way to communicate in a transparent way how new *big* feature
> changes could be done.

It's a problem if you can't easily be sure of the specifics until you
actually start trying to implement the changes.

The intended changes to the display architecture stem primarily from
general principles rather than having a complete replacement fleshed
out.

Initially, the main principles are:

1. No interaction features; output-only.
2. No separate driver process.
3. Backward compatibility with existing d.* commands.

IOW, the changes are primarily re-structuring, intended to facilitate
(undetermined) future changes.

A simpler system would make it easier to add new primitives and to
migrate d.* modules to higher-level interfaces, and would simplify the
creation of the GUI.

I don't have any concrete plans beyond that. I have lots of vague
ideas, but there isn't much point going into detail, as many of them
need to be evaluated in terms of the impact upon existing code, which
will involve a fair amount of exploration. And that part is best left
until it's easier to conduct such exploration.

-- 
Glynn Clements <glynn at gclements.plus.com>