On Fri, 12 Nov 1999, Gilles Detillieux wrote:
> Date: Fri, 12 Nov 1999 16:46:12 -0600 (CST)
> From: Gilles Detillieux <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [htdig3-dev] About HtDig Patch Sites
>
> 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.
I religiously follow the mailing list and pick up patches as they
arrive, but I am not infallible;) There is a README file at the site:
ftp://sol.ccsf.cc.ca.us/htdig-patches/README
Here are some excepts:
___________________________________________________________________________
..
etc. These patches come from the "ht://Dig mailing list" <[EMAIL PROTECTED]>,
"ht://Dig List Archives" <http://wormhole.eosys.com/mail-archives/htdig/>,
..
If you have comments or suggestions, though, we'd like to hear them.
Please email them to the address below.
If you have patches to add, please leave them in our /incoming directory
(ftp://sol.ccsf.cc.ca.us/incoming/) and send us email to tell us the
..
Our address: [EMAIL PROTECTED]
___________________________________________________________________________
> 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.
I agree with your suggestion; however, I think patch names should be
somewhat expressive of what file(s) they patch, but I will honor the patch
names authors choose. The subject of the patch email that is sent to the
list should be short and descriptive of the patch, as much as possible.
> 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.
Thank you for the complement; I also think it a good idea to have two
sites, in case one becomes unreachable at times.
> 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?
I believe in history and archives; I think it is a good idea not to
destroy any document because they may turn out to be helpful to someone
in some way. That's why I use a numbering scheme to signify chronology
patches; i.e.
thisPatch.cc.0
thisPatch.cc.1
...
thatPatch.cc.0
thatPatch.cc.1
..
There must be a better way of doing that; I am open to suggestions.
> > - 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.
Dittos;)
> 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.
I believe a 3.1.4 release will be welcome to many users, including
your's truly;)
Regards,
Joe
--
_/ _/_/_/ _/ ____________ __o
_/ _/ _/ _/ ______________ _-\<,_
_/ _/ _/_/_/ _/ _/ ......(_)/ (_)
_/_/ oe _/ _/. _/_/ ah [EMAIL PROTECTED]
------------------------------------
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.
