[cdr-discuss] CDR follow ups...

[Didier Verna]

Pascal Costanza wrote:

> There are two elements being proposed: (a) having something like
> :cdr-nnn in *features*, and (b) having a standard package naming
> mechanism. One suggestion actually was to have :cdr-nnn also as a
> package name.

  One more thing to consider is that it may not necessarily be a good
thing to have the implemented CDRs active by default. For instance, I
would like to be able to (require :cdr-nnn) when I want one, but also be
able to live without it if I want to. If that were possible, I think the
whole discussion on #; could just go away ;-)


> There is indeed no way to figure out which CDR is an update to which
> other CDR. My opinion is that this should be kept like this. There
> could be situations where different people have different views on
> whether a particular CDR is an improvement on a previous one or not,
> and there shouldn't be a mechanism in place that can be abused in any
> way for political reasons. Just my 0.02€. ;)

  Okay, so s/update to/based on/. Regardless of any judgment of value, I
still think it would be useful to have a tree (graph?) view on the
available CDRs, their update/fork/merge/dependency/younameit history.

Maybe a denotation mechanism is not needed. Every CDR can perfectly
state that it considers itself as a followup, update or whatever else to
another another one. Every CDR can also perfectly state that some others
are required for it to work. But if the whole CDR thing is to grow, I
fear that the situation could become messy. The point is just to make
that kind of information easier to get; not to force any particular
usage of it.

In practice, nothing prevents you from writing "this CDR is considered
an improvement over CDR #". But nothing prevents you from completely
disregarding that statement either :-)


-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com