* viper portability [Re: Viper hoses describe-key{, -briefly} in xemacs]
[not found] <22309.1181843643@cs.sunysb.edu>
@ 2007-06-14 18:32 ` Ilya N. Golubev
0 siblings, 0 replies; only message in thread
From: Ilya N. Golubev @ 2007-06-14 18:32 UTC (permalink / raw)
To: Michael Kifer, Chong Yidong; +Cc: bug-gnu-emacs, xemacs-beta
> This change was done by somebody in the emacs trunk.
That is, by Chong Yidong <cyd@stupidchicken.com> (whom cc-ing),
recorded as 2007-03-21 one in emacs `ChangeLog', `viper.el' revision
1.101 of 2007-03-21 16:18:25 +0000. Whoever do changes like this,
they must understand the following.
> I did not test it on xemacs when I merged this with my changes.
That is, changes of viper code in emacs cvs can easily go into xemacs
package cvs without any checks. In other words, the code in emacs cvs
has to be portable to xemacs also, it is normally expected to work in
both emacs and xemacs.
Nothing states that explicitly, as a requirement for (or at
least a request to) developers. Only comment in `viper.el' says that
the software is
for Emacs and XEmacs
Comments in many other viper `.el' files do not mention even that.
What might help is `README' file in emacs cvs stating explicitly that
the development sources of viper are intended to be portable as above.
Another issue is updating xemacs package change log. Certainly if
some upstream (emacs cvs in this case) changes are merged there,
adding relevant upstream change log entries is also appropriate (in
the same file or in a separate one is a matter of taste). The very
glance at entries for changes one is going to merge can help detect
the appearance of non- portable code, so that one can at least delay
merging that particular change.
^ permalink raw reply [flat|nested] only message in thread