Adam Sjøgren writes:
On Thu, 18 Nov 2010 04:37:05 +0900, Stephen wrote:
> You misunderstand the situation, then. Jerry dropped the ball; after
> making some comments on the original report, he's been silent on the
In my eyes Jerry James provided valuable insight into what the problem is.
I don't know how that is dropping the ball.
Because in a project operated by volunteers, all work is done by
individual decision. Normally, when someone comments on an issue,
others assume he has interest *and will follow up*. They will not go
out of their to work on the issue unless they have a specific
interest. That is why we use the metaphor "pick up the ball";
typically only one person works on reviewing a given issue. If they
stop working or commenting without saying "hey, I don't have time to
work on this, will somebody pick up the slack?", that is "dropping the
ball"; somebody else needs to notice it and pick it up or nothing will
Note that I'm not criticizing Jerry; he probably looks at your message
every day thinking "I'm going to get to that later, well, tomorrow...".
But that leaves you out in the cold, so after a few days Mats stepped
I see that I have been totally unable to convey my message to you at
No, I understand exactly what you're saying. I'm simply explaining
why things work (or don't work, if you prefer) the way they do.
I am NOT asking you to commit the patch, nor to try it on an OpenBSD
system. I am just, and only, asking: DOES IT LOOK SANE?
I know that, and you are ignoring my answer: I myself will reserve
judgment until I know more about the problem, and can properly test
the proposal and see what happens in reality. Other reviewers work
differently, perhaps, but unfortunately none of them seems to be
available and interested in continuing work on your patch.
Since you feel it necessary to shout, I'll be more specific. My
knee-jerk response is "this kind of logic belongs in configure.ac (or
perhaps config.h.in), not in a .c file, or even .h". But that's just
my initial reaction, where I would *start* the review. Making that
judgment is not trivial for me because I know the unexec code is very
special, and because it likely implies a lot of extra work for
somebody, preferably you. Since you keep emphasizing how lazy you
are, *I* hesitate to ask. :-) Jerry can probably answer a lot more
quickly and authoritatively, but he's not posting at the moment.
If it does, I'll be happy to read up on any procedures and submit
test and approval. If it doesn't, just let me know, and I will try and
That is the way contribution by newcomers works most places, I have
You are clearly not getting *my* message, which is that most of the
time that is the way things work here.
Since you don't want to do it yourself, I have reposted your patches
with a ChangeLog to XEmacs Patches. It is, of course, better from our
point of view if you do it. That saves us a bit of time and in some
sense increases your attachment to XEmacs. That's why Mats asked you
to do that. But it's not a big deal for me to do it, of course.
However, the rest of the thread is not responding to your patch; it's
responding to your comments about the workflow. If you think our
workflow is broken, I want to explain how it really works. Even
though I would like to improve it, changing workflows in a project
with a history as long as ours takes quite a long time and much
effort; it probably won't happen quickly enough to make you happy.
Heck, I have even used it before for XEmacs:
Maybe I was just lucky :-)
No, that is normal. *This time* you are unlucky.
XEmacs-Beta mailing list