>>>> "Mike" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Hrvoje> "Stephen J. Turnbull"
<turnbull(a)sk.tsukuba.ac.jp> writes:
>> Not for the release. The rules have changed. I've
explained how
>> this is going to work. The Release Manager says "no", and unless
>> the Review Board overrules, the veto rides.
Hrvoje> We never agreed to these rules. You're inventing them as you go
Hrvoje> along.
Mike> I don't think so. The way I remember it, Stephen was quite explicit
Mike> about this aspect of the whole thing well in advance. Incidentally, I
Mike> agree, even though Stephen did veto one or two things *I* wanted in
Mike> the release.
Hrvoje> Even Ben didn't dare do that.
Mike> We're not talking about code not making it into XEmacs in general,
Mike> we're talking about code not making it into this specific release, for
Mike> which Stephen has accepted significant responsibility.
Mike> I'm sure he has no objections against putting it into the
Mike> soon-to-be-opened development branch.
Well, since Stephen is doing so much of the work on 21.4, he gets to
have slightly more dictatorial powers than usual for a member of xemacs-review.
The situation is similar with Vin's 21.1. However, when there's a
feature that consensus wants to keep in the core, Stephen shouldn't be
able to remove it unless there's a CVS separate branch for 21.4, or
Stephen _promises_ to put it back himself. However, be aware that
removing this kind of a feature might itself be rather risky.
Regarding the technical issue, if a random function that calls
next-line behaves differently depending on its keybinding, then that
is a serious bug.
I agree with the idea that function behavior should not depend on
binding, with a few exceptions like self-insert-key. If you want
shifted motion keys to have particular behaviors, use the standard
keybinding api to define new functions for the shifted keys. But this
design question alone should not inhibit a release of 21.4.
Martin