IMO, as soon as you accept responsiblity you should list yourself, so that
reviewers know they need to check with you before approving patches to
that package. You can set a policy that they can commit anything they like,
of course, but it's *your* package, you are the boss. There are checks and
balances (Norbert can approve patches as "package czar", and security risks
or code that tickles crashes in versions still in use can be approved by any
reviewer), but the basic idea is that we stay out of your way until
you invite us
in.
On 10/13/07, mike.kupfer(a)xemacs.org <mike.kupfer(a)xemacs.org> wrote:
QUERY
> * mh-utils.el (mh-funcall-if-exists):
> If a function is bound at compile time, that has a limited amount
> to do with whether it's bound at runtime. Don't trust the check at
> compile time, use the runtime check instead.
In MH-E 8 (which I am slowly... very slowly :-( ... getting ready for
the package build), mh-funcall-if-exists looks like
(when (fboundp function)
`(when (fboundp ',function)
(funcall ',function ,ļ¼ args))))
That is, if the function isn't bound at compile time, don't bother
checking at runtime. Is that going to be a problem?
Also, will I need to do a test-build with a non-X11 XEmacs before
committing?
And one organizational question: I was holding off on listing myself as
the MH-E maintainer until I got the MH-E 8 update in shape. Maybe I
ought to list myself now?
thanks,
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta