Re: pcl-cvs synching issues
Greg Klanderman <greg(a)alphatech.com> writes in xemacs-beta(a)xemacs.org:
Hi,
I'm in the process of committing Karl's synching work on
pcl-cvs and
want to raise a few issues.
- First, the elib stuff has been removed from pcl-cvs. Hence
Karl's
elib package needs to be imported into the cvs.xemacs.org
repository and package-compile.el needs updating.
O.K. I will add this package after the SUMO package tarball is consed
up.
- The file generic-sc.el is included in the pcl-cvs package but is
not actually part of pcl-cvs. I would like our pcl-cvs package to
mirror the one distributed by Greg Woods (he will fold in our
changes) so I feel generic-sc should be moved elsewhere.
Suggestions?
/dev/null?
Probably prog-modes is as good a place to put it as any.
- There are several other .el's that come with pcl-cvs as
distributed by Greg Woods which are primarily for debugging and
should not make it into the binkits. I would still like them to
appear in the srckits and in the repository. Currently we have in
XEmacs.rules:
$(RCOPY) ChangeLog *.el* $(EXTRA_SOURCES)
$(STAGING)/lisp/$(PACKAGE)
the "*.el*" part is kinda losing... I'm sending a
patch that
creates a variable settable from a package makefile. It will
default to "*.el*" if unset.
O.K. I think I applied this patch. The `*.el*' is wrong. It should
be `$(ELCS) $(ELCS:.elc=.el) $(MULE_ELCS) $(MULE_ELCS:.elc=.el)'.
- I have tagged our previos pcl-cvs package as
"pcl-cvs-r1-11". I
am recommending that XEmacs 21.0 distribute this version since there
is further synching and testing to be done before I'm confident of
releasing the newer version.
(We've already discussed offline the dangers of making the
distribution branch a non-default branch and I think the mess is
cleaned up).
Please don't do this. Please keep development branches off the
mainline so the lisp package builder doesn't have to think to update a
lisp package, or ...
In terms of formal policy, Oscar Figueiredo has written something up
acceptable to me. Comments?
Now that we have had package source corruption, it is very important
to get rigid standards in place.
Attachments:
- attachment.mht (message/rfc822 — 52 bytes)