According to J. op den Brouw:
> In his e-mail on 17 mar 1998
> (http://www.htdig.org/mail/1998/04/0017.html),
> Joe R. Jah ([EMAIL PROTECTED]) sort-of
> announced his unofficial patch site. Some weeks ago, Gilles released a
> patch and it was put on the htdig server. Needless to say, that
> people are looking at two different places for patches. The
> htdig dev site point to Joe's site, whereas Gilles placed his
> patches under http://www.htdig.org/files/contrib/other/.
I have to admit that this confusion was caused by my ignorance. I came
on the scene last September, so I missed Joe's announcement of his
unofficial patch site. While I had heard some vague references to this
site afterward, I didn't know where it was or who was maintaining it.
I missed the link on the dev.htdig.org web site, until Jesse pointed
it out to me last week. Until then, for the past couple months, I was
using contrib/other for my own patches.
Even so, after finding the patch site, I couldn't find any information
on there about who was maintaining it, how methodically patches were
being archived from the list, or whether there were any guidelines for
patch submission.
> Anyway, this would not need to be a problem as long as the two sites
> use the same name.
That's a good point. I had trouble finding my own patches on Joe's
site because of the different names. I'm not sure what the solution is,
short of suggesting patch names when submitting them to the mailing list.
> While in conversation with Geoff, the idea came to life to let our
> minds go on:
>
> - Should we have to sites:
> If yes, should they be an exact copy.
> If not, which one will go on?
Personally, I get the impression Joe's doing a pretty thorough job, as far
as I can tell, so if we're going with just one, I'd say we go with his.
It would be a good idea if we mirrored it on htdig.org, though.
> - Naming conventions.
> - "Tested", "Untested", "Recommended",
> "Do-not-use-unless-you-really-have-problems".
I guess we'd also want a mechanism for overriding or replacing patches
with corrected versions. I've submitted patches from time to time, only
to have someone point out a correction. I've also found some posted
patches that were in need of corrections (e.g. a patch that tested a
boolean parameter as a string, comparing it against "0", rather than
using config.Boolean()). When a corrected patch is submitted, the
defective one should be taken off - how will this be specified?
> - Which of the patches go into the next release.
That's always up to the discretion of the developers, but without a
formalized process for this, patches do get forgotten. I've been
pretty thorough about making sure my own fixes make it into 3.2,
but I know I've let a lot of other patches slip through the cracks.
Usually someone else gets them, but not always.
A related question is "what are the next releases?" I know that
3.2.0b1 is in the works, and there's still some work going into the main
3.2 branch, into which I'm sure the 3.2.0b1 changes will get merged.
Since 3.1.3, I've only been updating the 3.2.0b1 branch, but I'm always
wondering if I shouldn't also update 3.1.x (for an eventual 3.1.4
maintenance release) to fix the infamous bare ampersand clobbering
problem as well as a few other bugs and enhancements.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
