Marcus Harnisch writes: Yay! And you bet I would ask. ;-) Since you're already a package maintainer, I've extended your permissions to prog-modes/verilog-mode.el and prog-modes/prog-modes.texi. The restriction from committing to other files in that package is for your convenience, so that an inadvertent "cvs commit ." doesn't muck up the tree if you have changes to other files. If you want further permissions (eg, to Makefile), don't hesitate to ask. I don't think you need that though, since most files will be maintained by XEmacs Dev Team still. Also, the bug reports and so on will be left directed to xemacs-beta for the same reason. Norbert, please add Marcus to MAINTAINERS for verilog-mode.el. The best you can hope for is either communication with the original packager or maybe the initial import was pristine. What are you worried about? If we can help, let us know. Changes that need to be made against upstream to conform to XEmacs packaging "should" be marked ";; XEmacs change". Changes that are due to XEmacs vs. GNU API differences "should" be marked ";; XEmacs change" and reported to one or both of upstream (as an RFE) or xemacs-beta (as a bug). If such changes were left unmarked, you'll find out soon enough as a regression will occur. Any unmarked changes are presumed regressions against current. If you want to be careful not to lose any possible improvements, you can review them individually and triage them as (a) old versions of upstream, (b) unmarked XEmacs changes, or (c) improvements that never made it into upstream, with obvious implications for what you need to do. One approach you can use is to use a vendor branch in CVS, and use "cvs merge" to merge the new code into the old package. (Or even better, do this locally with a modern VCS.) If you don't want to do that (feel free, I won't criticize!), then just pull in the current upstream and make any necessary "XEmacs changes" (and mark them, s'il vous plait). Advise Norbert that these changes need a relatively long prerelease time to catch any regressions. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Marcus Harnisch writes: Oops, sorry. Will do later today. Also the cedet-common module, if Norbert doesn't get to them first. Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Hi Stephen "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: $ cvs ci ChangeLog prog-modes.texi verilog-mode.el Enter passphrase for key 'xxxxxxxxxxxxxxxxxxxx': **** Access denied: Insufficient Karma (mharnisch|XEmacs/packages/xemacs-packages/prog-modes) cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! cvs commit: saving log message in /tmp/cvshMqvVt $ Checking in all files individually causes no problems. Strange. I wonder whether "cvs ci ." would have made a difference. But then, the above is what pcl-cvs did, too. -- Marcus _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta