On Thu, 18 Nov 2010 01:47:46 +0900, Stephen wrote:
> I understand that it is nice to have people use your specialized
> and workflows to submit patches.
Patcher is not a specialized tool.
Ok; I have never heard of it outside XEmacs, and I have been running
GNU/Linux exclusively since autumn 1994.
Granted, I have only contributed with very teeny tiny couple-of-lines
patches to various things (Gnus, DBD::Pg, BioPerl, XEmacs, PostgreSQL).
Now that I am whining anyway: I find the emails in xemacs-patches wholly
confusing; often the same patch is posted multiple times, and then
months later with a different prefix in the Subject header, and so on.
[... How to make patches ...]
I don't see anything unusual or difficult there, unless
contributed to any project on the 'net before.
I agree, but you are missing my point entirely.
Every project has different ways to receive contributions (this or that
option to diff, this or that mailing list, patches inline, in
attachments, uploaded to a bugtracker, pull requests, etc. etc.).
I am lazy, so I don't care to study those requirements _until_ I think
what I am contributing is good enough to go straight in without any
checking (which it of course will get anyway) or modification. Until
then, I am merely discussing and suggesting on the mailinglist for
I can see now that it was a mistake to include a patch as part of my
discussion here. Other places a patch signifies "At least he is serious
enough to try fixing it himself, he isn't only whining".
[... hoping for feedback ...]
But in this case perhaps a bit optimistic, as this is a rather
technical detail, and we don't have active OpenBSD-based developers at
Perhaps it is optimistic, but is the solution really to submit the patch
in exactly the right way? Does thath magically activate experts in this
Anyway, I don't think it requires a lot of specific OpenBSD insight to
answer - the change basically takes the observation by Jerry James (Hey,
ElfW ends up being 32-bit) and tries to remedy it by looking at a
compiler-define. _LP64 is a generic define that gcc sets if the platform
is 64 bit - there is no esoteric OpenBSD-specific stuff in the question.
That is, you're probably the best expert we've got. :-) And
know what I'm saying. :-)
I know the changes I suggested make the build continue further on
OpenBSD, that isn't what I am asking (maybe I am also being unclear on
that); what I was trying to say was: "Does this change look reasonable
seen from an XEmacs-codebase perspective?"
> As a green newcomer, I don't want to learn - and go through -
> hoops to send a patch only to have someone say that it should have been
> fixed in a slightly different way.
You don't have to learn them. The only folks who *have* to learn
are the reviewers.
It seems I do, because the only reply to my attempts to move this build
along has been suggestions to follow the rules to make my patch look
less unserious (which isn't what I aimed for, but anyway).
But if the patch is undocumented (minimum of a ChangeLog entry), or
doesn't apply, or it is directed to the wrong list, it is less likely
to get the attention it deserves. And every project I've ever worked
on works that way; some are much more formal. We're not going to
deliberately ignore your patch, but with no expertise on that
platform, everybody is hoping for somebody else to do something. I
know I'm hoping Aidan will, because I don't expect to have time to
work on code I don't understand until Christmastime. :-)
I must have been very unclear. I wasn't trying to ask for an OpenBSD
developer to jump up from under a rock, I was trying to ask whether the
change illustrated makes sense seen through the eyes of anyone who
usually hacks on XEmacs.
And I am pretty sure that any one of you commit-bit-wielders could have
thought about _LP64 and either answered "nah, not good" or committed the
change in a fraction of the time it took to read this thread.
"Vilken sanning, Måns, är sann?" Adam Sjøgren
XEmacs-Beta mailing list