> * Another showstopper is the apparent lack of will to help
> newcomers solving their problems. OK, it's August. But I don't see
> how you can expect to get more people involved in the developpement
> if you don't help them getting started.
I'm not sure I've seen this. I've personally looked over someone's
SMOB code (Telford?). I don't know your direct experience, but I see
people being helpful pretty frequently.
I think this is really a side effect of the lack of documentation. If
newcomers had a coherent manual to chew on, there would be fewer
questions, so each one could get more energy spent on it.
> * You can't either expect people to use the snapshots. People
> need stable releases. I'm not against the idea of moving the API, if
> it can improve it. But people must be informed of the incompatible
> changes from stable release to stable release.
Right. I think there's also a psychological significance to real
releases.
> * As far as I could see, but again, this is a newbie view, the gh API
> seems strange, uncomplete and inconsistent. Some examples:
>
> - Why using so many functions with just a `return' line, instead of a
> set of standardized macros ? Something like BOOLEAN_P instead of
> gh_boolean_p.
gh_ has some gaps, as I said in a previous message.
The function vs. macro debate is an old one between myself and Mark
Galassi (gh_'s author). It's not a cut-and-dried decision in all
cases, but certain things should definitely be macros. I just need to
introduce Mark to the muzzle of my Saturday Night Special, and this'll
get straightened out, toute suite.