Re: Exmh FreeBSD port

If it would help, I can add Joel to the source forge committer list.
I'll really need to make a new tarball release, call it 2.8.0, that
reflects the CVS head.  I'd like to get the "patch_exmh.sh" script
into that release, probably naming it "patch_exmh_freebsd.sh" or
something, and train the little sed script that knows about version
numbers to fix it up.

>>>Joel Hatton said:
 > 
 > Hi,
 > 
 > First, thanks for all your replies - I didn't know if my message would
 > generate such response! Valdis, forgive me for picking on you to respond
 > to directly but yours was the last message, and I had to pick someone :)
 > 
 > On Wed, 26 Jul 2006 22:07:08 -0400, [email protected] wrote:
 > >
 > >1) I'd not be surprised if most of the big CVS committers are a bit 
rusty
 > >on working with CVS branches.
 > >
 > >2) I doubt we can only get notifications for commits to HEAD (which 
would
 > >mean work on a branch would be silent till the branch got merged again).
 > >
 > >Oh well...
 > 
 > I've reflected some more on this overnight, and I've thought of an 
approach
 > to the port that might work ok and reduce the workload on the exmh
 > committers. I'm definitely appreciative of the effort that people like
 > Chris (who I'm sure underrates his expertise in tcl/tk) have put into 
exmh,
 > and I don't want to make any more work for them than absolutely 
necessary.
 > 
 > My alternative method:
 > 
 > 	o leave the current backend of exmh development the same ie major
 > 	releases relatively long-term and static, with ongoing development
 > 	in cvs
 > 
 > 	o retain the current mail/exmh2 port and its relationship to major
 > 	exmh version
 > 
 > 	o check out the cvs regularly at HEAD (probably the most practical)
 > 	and
 > 
 > 	o automate a context diff between the changes in HEAD and the files
 > 	in the major release to generate patch files like in the current
 > 	port eg mail/exmh2/files/patch-lib-folder.tcl
 > 
 > 	o commit the port with suitable PORTREVISION and PORTEPOCH numbers
 > 	(of which I know not much, but primarily to keep the PORTVERSION
 > 	in concert with release)
 > 
 > This way, the port could be updated without the need to retrieve a newer
 > .tar.gz file whenever a change is made in cvs, and no extra effort would
 > be required on the part of the developers - except maybe some extra 
queries
 > to -workers from me occasionally, just before I update the port!
 > 
 > I'm going to bash up a script to produce the patch files, but I'd like
 > some thoughts on this approach if possible. If creating an exmh-devel 
port
 > is appropriate, I'm sure that could be accommodated, even if just by 
using
 > the approach I've outlined here.
 > 
 > cheers,
 > -- Joel Hatton --
 > Infrastructure Manager              | Hotline: +61 7 3365 4417
 > AusCERT - Australia's national CERT | Fax:     +61 7 3365 7031
 > The University of Queensland        | WWW:     www.auscert.org.au
 > Qld 4072 Australia                  | Email:   [email protected]
 > 
 > _______________________________________________
 > Exmh-users mailing list
 > [email protected]
 > https://www.redhat.com/mailman/listinfo/exmh-users
 > 
 > 

--
Brent Welch
Software Architect, Panasas Inc
Accelerating Time to Results(tm) with Clustered Storage

www.panasas.com
[email protected]