Re: I resign as Guile maintainer

[Greg Harvey <Greg dot Harvey at thezone dot net>]

(note: I snipped out most of the cc's, since I didn't want to be
bombing everybody... this is sort of tangential and belongs more on
the list than the mailboxes of half the free software community ;).

Ken Raeburn <raeburn@raeburn.org> writes:


> > I would recommend any of the following people as replacements:
> > [...]
> > Ken Raeburn <raeburn@raeburn.org>
> > [...]
> > There are certainly others who are qualified.  These are simply people
> > who have caught my notice in some way or another.
> 
> Um, thanks for the mention, but if real development work and guidance
> is what is needed, you need someone more in tune than I am with The
> Vision Of Where We Should Be Going and what other groups in the
> Lisp/Scheme worlds are doing.  Now, mere application stuff (like
> Emacs:-), that I can hack, when I've got time....
> 
> I won't say "don't pick me" in so many words; if mere coordination and
> release management and a somewhat cloudy Vision will do, and no one
> else volunteers, maybe I can help.  But I hope someone (or more than
> one) much better qualified than I will be able to step forward and
> pick up the mantle.  Several people have been suggested who are still
> actively doing work....

I think what would make a good maintainer is a collection of the
following:

1) Able to devote time to guile. This is a very big one. It doesn't
   have to be 10 hours a day, but it should be a few hours a week (not
   necessarily contiguous :) to look at code & patches, and follow up
   bug reports (though this can also go to other
   developers). Participation on the mailing list is a real plus, too
   (it gives you a warm fuzzy feeling to get a response from the
   maintainer :).

2) Not necessarily someone who's doing a lot of development. Actually,
   I'd snip most of the people from the list that Klaus Schilling
   posted for exactly that reason; other stuff would likely be
   neglected while they worked on their pet project, or their pet
   project, usually very beneficial to guile, would be neglected in
   favour of other stuff.

3) Someone with an understanding of how most of guile works. Not
   necessarily having the code memoized (what an eval pun), but they
   should be able to know (or find out quickly) what a particular
   piece of code does (so, no one afraid of eval :).

4) A good eye for bad code ;)


-- 
Greg