[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
them.
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
platforms.
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.
--lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail