Re: Building on 64 bit OpenBSD; ElfW

Adam Sjøgren writes: 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 get done. 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 up. 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 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. 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. No, that is normal. *This time* you are unlucky. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta