[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] edginess

From: Lyndon Nerenberg
Subject: Re: [Nmh-workers] edginess
Date: Mon, 26 Dec 2011 11:34:24 -0800

On 2011-12-26, at 10:13 AM, Paul Vixie wrote:

> the time we spend discussing these things and working on separate
> branches and then carefully merging those branches in, comes out of our
> development budget. none of this work is controversial.

Branches are cheap. They are a great place to experiment without breaking the 
production code.  And the posix stuff is not free of controversy.  My primary 
motivation for doing the work is to free the code base from autoconf; there are 
others who want the opposite.  So the posix branch is much more than API 
changes -- it's a proof of concept that it's possible in this day and age to 
ship a source tree that builds on multiple UNIX variants without needing 
autoconf.  Yes, you and I know it's possible, but we're dealing with a 
generation of programmers who have never experienced a build tree free from 
autoconf hell.  Rather than argue the point, I figure it's easier to just show 

Also, asking about vfork is a legitimate question.  I don't have access to the 
variety of platforms I had ten years ago, so I don't know if vfork() still 
provides an optimization.  I'm not going to blindly rip the code out in the 
interest of 'progress' until I know it's not going to pessimize current 

And as I mentioned earlier, I'm trying to break things up into functional 
commits that are easy to merge onto the head.  What we really need is to task 
someone to analyze the commits I'm making on the posix branch and merge the 
straight-forward stuff onto the head.

MH has been an incredibly stable piece of code over its lifetime.  I am loath 
to change that just for the sake of progress.  Forking is not evil.  Hell, nmh 
itself forked from MH source tree.  Branches are a cheap and easy way to fork 
the code to try out new things.  If they work, they can be merged to the 
production code base.  nmh isn't so complex that merging is a big issue.  The 
trick is using rebase prudently to keep the branches from wandering too far 
apart.  It's doable, given a modicum of discipline.  git has the functionality 
to do this – it's just a pain in the ass to figure out how to do it.  I bought 
a copy of the _Pragmatic Guide to Git_ which has been a considerable help as I 
try to figure all this out.  (My previously botched git branch wouldn't have 
happened had I read the book first.)

I understand what you're getting at, Paul, and I am in agreement.  But after a 
25 year friendship with MH, I just not in a tearing hurry to change everything 
right this second.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

reply via email to

[Prev in Thread] Current Thread [Next in Thread]