Adam Sjøgren writes:
Now that I am whining anyway: I find the emails in xemacs-patches
wholly
confusing; often the same patch is posted multiple times,
xemacs-patches is primarily part of the review workflow. Patches
submitted with intent to commit will be reviewed there, but design
discussion before submission (including proof-of-concept patches)
takes place on xemacs-beta. So given the intention you describe,
posting to xemacs-beta was the right thing to do. However, Mats is
also right; if there is a working patch, and nobody's doing anything
right away, xemacs-patches is where it will be found later.
The only time a non-reviewer needs to follow xemacs-patches is when
they have a patch actively in consideration, and then the normal
practice is to leave you in the Cc list, so you probably don't need to
subscribe.
Regarding duplicates, among other things, the commit notices get
posted there, as well as review notices (approvals and commits) etc.
I trim; the commit bot and lots of people don't, so you'll see the
same patch multiple times. We also have three more-or-less active
branches (21.4, 21.5, and carbon2); patches will often be submitted
for one of the above and only later determined to be relevant to
others. carbon2 also gets synched to the mainline on a fairly
irregular basis.
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
technical area?
No and no. You are not required to submit patches in exactly the
right way. Your submissions are not moderated, and they will be
considered when somebody has the time to do so, regardless of whether
you follow the formatting recommendation. That is, if they are found
in the place where we looking for unreviewed patches: our
xemacs-patches folders.
We don't have any experts on OpenBSD or 64-bit-cleanness AFAIK;
therefore no magic will activate them.
> You don't have to learn them. The only folks who *have* to
learn them
> 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).
You misunderstand the situation, then. Jerry dropped the ball; after
making some comments on the original report, he's been silent on the
subject. That happens; we are all volunteers, after all, and
sometimes real life takes precedence. When Mats recognized that, he
stepped in to try to ensure that the patch stays on our radar,
although he apparently doesn't have the expertise to review the patch
himself. Isn't that the way things *should* work?
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.
I assure that is not true in my case. I do a build and test run
before committing, which in this case means finding a place to install
OpenBSD and installing it. Heck, before that, I'd need to find an
installable distribution. (I don't expect that would be hard, but
these little details add up to quite a time commitment.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta