Re: Anyone home?
First off, let me say that I didn't mean to suggest stepping on anyone's toes -- I certainly feel that Dan and Doug have done the world a service, and I respect that. I threw out SF as an option because it would let us beat on an `interim release' or similar without disturbing the current mhost stuff. I almost suggested Savanah, but I wanted to avoid the license question; it sounds like that's a non-issue. If Doug's willing, we're probably better off just working from a new module on mhost. Given that mh and nmh are both pretty stable at this point, and that there are issues with major features and compatibility (such as the pernicious date parsing discussions), I'd suggest starting work on a new `major version', so we wouldn't need to feel so bad about the various incompatibilities. Aside from the bug fixes, I think we've agreed in the past that mh should have better support for MIME and IMAP, and that both will be somewhat complicated; I'm sure that there are other big projects to consider. I suggested 1 Jan as a minimum time to give everyone a chance to respond; like Ken, I am moved by the quick responses. Let's see what we can do. To directly address Peter's question: yes, I believe that the proposed changes could be nice for mh-e support, but they don't seem very close to `deployed' to me right now. I'm including Jon Stienhart's message below. chad --- Forwarded Message Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: again - New code that simplifies user interface for MIME attachments to a draft MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=- =_aa0 Content-ID: [EMAIL PROTECTED] Date: Thu, 05 Jul 2001 08:01:34 -0700 From: Jon Steinhart [EMAIL PROTECTED] - --- =_aa0 Content-Type: text/plain; name=sendQ59nO_; x-unix-mode=0644; charset=us-ascii Content-ID: [EMAIL PROTECTED] Content-Description: English text Well, that was embarassing. A last minute fix created a bug in the stuff that I just sent. Here it is again with the bug fixed... I posted some code that improved the user interface for adding MIME attachments to messages some months ago. While the code worked fine, I didn't really like the way that I had implemented it and have subsequently done it over. Since I don't have write access to the CVS, please look it over and check it in if it looks OK to you. If it doesn't, let me know what you think should be changed. Here's the contents of the README-ATTACHMENTS file that is included with the patches: Jon Steinhart's ([EMAIL PROTECTED]) Attachment Handling Patches ~~~ Attached are a set of patches designed to improve the nmh user interface for handling MIME attachments. Why Did I Do This? ~~ Although nmh contains the necessary functionality for MIME message handing, the interface to this functionality is pretty obtuse. There's no way that I'm ever going to convince my partner to write mhbuild composition files! And even though I know how to write them, I often screw up when sending a message that contains a shell script because I forget that I have to double any # at the start of a line, which shell scripts have galore. These patches simplify the task of managing attachments on draft files. They allow attachments to be added, listed, and deleted. MIME messages are automatically created when drafts with attachments are sent. Did I Do This Correctly? Hard to say. Despite lots of time looking at the nmh code, I can't say that I get the philosophy behind its structure. I am aware of two deviations from what I saw in the nmh code. 1. I commented my changes. 2. It's been years since I've used a VT-100, so I don't try to make code fit into 80 columns anymore. Seems silly to me. What Did I Do? ~~ I made changes to the following files: h/ prototypes.h man/ anno.man send.man whatnow.man uip/ Makefile.in anno.c annosbr.c send.c sendsbr.c viamail.c (needed change for new sendsbr argument) whatnowsbr.c Attachments are associated with messages using header fields. For example, a draft that looks like this To: jon Subject: test of attachments X-MH-Attachment: /export/home/jon/foo X-MH-Attachment: /export/home/jon/bar X-MH-Attachment: /export/home/jon/test/foo has the files foo, bar, and foo as attachments. Although I use the header field name X-MH-Attachment to indicate attachments, the implementation allows any header field name. The advantage of using header fields is that the list of attachments travels with the draft so it remains valid across editing sessions. Note that the header fields for attachments are removed from
Re: my attachment code
Well, since Chad just reposted my attachment code, let me tell you what's wrong with it. I'll update it if work is really going to happen on a new release. I use anno to add attachment headers. Anno works by prepending headers to a message. Unfortunately, this means that if you add several attachments to a message, they'll come out in reverse order. I am planning to change anno to append header fields instead. Can't see how this would break any existing applications. If anyone is worried about this, I can add a prepend/append option but that seems unnecessarily complex to me. Jon
Re: my attachment code, plus attachments in general
I I would personally like there to be no difference between reading messages and reading attachments. In other words, I don't want to have to use a different UI because someone sends me a message with 3 attachments as opposed to 3 messages. I strongly agree, but want a new command name so that old scripts keep working. Laura Creighton
FCC vrs. BCC/DCC
I've noticed that when I send a message, any BCC or DCC recipients do not appear in the copy saved via FCC. This behavior is consistent with the send(1) man page, but IMHO, that behavior is broken. I understand that the recipients should be hidden for outbound mail, but I believe that the file copy should show everyone to whom the message was addressed. Specifically, I'd like the thing that's saved with FCC to be the message as it appeared when send was called, plus the Date: and Message-id: headers (yes, I have send: -msgid in my ~/.mh_profile). So, does the way I envision the ideal behavior of FCC: break any specifications? Is it even possible? Could it simply be an option in the .mh_profile to choose the Fcc style? Mark Bergman
Re: Anyone home?
New module? No, that is just not the way CVS is supposed to be used. Maybe a seperate branch if radical changes are going to be made, but HEAD is the appropriate place for most development. Hmm. While I agree with you, and I'm certainly willing to try it, I have to say that most of the time I've seen people try to use separate branches for radically different versions of softare the results were at best `confusing'. That said, I'm all for trying it again.. :-) chad
Re: my attachment code, plus attachments in general
Hold up -- everyone back up a step. The most immediate concern is getting out a release that makes public the changes in CVS for the last 2 (?) years. This is not a good time to be making more changes on the main branch, as it will inevitably hold up the process more. This would be a good reason to make a branch for these types of exploration. Hopefully, all the people on this list have the CVS version installed on some machine, and have been using it for some time. If not, please do, so we can get at any egregious bugs. I have not seen any so far, but... Shantonu On Friday, December 7, 2001, at 11:59 AM, Laura Creighton wrote: While we are at it how about making repl -format include the name of the person that wrote the thing you are including , not just another set of Laura Creighton
Re: I am still considered a spammer it seems...
Please deal with Jon offline, since your mail is getting through to the rest of us. Shantonu On Friday, December 7, 2001, at 12:25 PM, Laura Creighton wrote: Return-Path: MAILER-DAEMON Delivery-Date: Fri Dec 7 18:21:51 2001 Return-Path: MAILER-DAEMON Received: from localhost (localhost) by theraft.strakt.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id fB7HLpBv023362; Fri, 7 Dec 2001 18:21:51 +0100 Date: Fri, 7 Dec 2001 18:21:51 +0100 From: Mail Delivery Subsystem MAILER-DAEMON Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary=fB7HLpBv023362.1007745711/theraft.strakt.com Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --fB7HLpBv023362.1007745711/theraft.strakt.com The original message was received at Fri, 7 Dec 2001 18:21:49 +0100 from [EMAIL PROTECTED] [62.13.29.37] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 550 5.0.0 Spam not spoken here) - Transcript of session follows - ... while talking to fourwinds.com.: MAIL From:[EMAIL PROTECTED] 550 5.0.0 Spam not spoken here 554 5.0.0 [EMAIL PROTECTED]... Service unavailable --fB7HLpBv023362.1007745711/theraft.strakt.com Content-Type: message/delivery-status Reporting-MTA: dns; theraft.strakt.com Received-From-MTA: DNS; ratthing-b246.strakt.com Arrival-Date: Fri, 7 Dec 2001 18:21:49 +0100 Final-Recipient: RFC822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 Diagnostic-Code: SMTP; 550 5.0.0 Spam not spoken here Last-Attempt-Date: Fri, 7 Dec 2001 18:21:51 +0100 --fB7HLpBv023362.1007745711/theraft.strakt.com Content-Type: message/rfc822 Return-Path: [EMAIL PROTECTED] Received: from ratthing-b246.strakt.com ([EMAIL PROTECTED] [62.13.29.37]) by theraft.strakt.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fB7HLnBv023360 for [EMAIL PROTECTED]; Fri, 7 Dec 2001 18:21:49 +0100 Received: from strakt.com (lac@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id fB7HLnua025163 for [EMAIL PROTECTED]; Fri, 7 Dec 2001 18:21:49 +0100 Message-Id: [EMAIL PROTECTED] To: Jon Steinhart [EMAIL PROTECTED] Subject: Re: fourwinds.com thinks I am a spammer for some reason. In-Reply-To: Your message of Fri, 07 Dec 2001 09:17:55 PST. [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: [EMAIL PROTECTED] Content-Transfer-Encoding: quoted-printable Date: Fri, 07 Dec 2001 18:21:49 +0100 From: Laura Creighton [EMAIL PROTECTED] Thanks very much. (You are getting tons of Spam from _Sweden_? Seriously? There is = another fix. I can tell you where to mail a piece of paper that makes it illegal to send you Spam, because you have registered as not wanting it. Then any Swedish company that sends you Spam can face big fines = here.) There has got to be another 62. though, I guess ... I am not sure how that works, actually. Laura Creighton (in G=F6teborg, Sweden)= --fB7HLpBv023362.1007745711/theraft.strakt.com--
Re: my attachment code, plus attachments in general
Oh, sorry, I thought I was in the Jon Steinhart wants opinions on major new features thread. Laura Creighton
CVS and branching
Doug wrote: New module? No, that is just not the way CVS is supposed to be used. Maybe a seperate branch if radical changes are going to be made, but HEAD is the appropriate place for most development. Yes, that is correct. I've worked quite a bit with CVS in the recent past and find it an invaluable tool for managing multiple branches and versions of a given piece of software. Modules in general refer to a subdirectory of a program rather than a version or branch of that program. Regardless, we don't need to get wrapped up in word semantics. Branching can be implemented fairly easily, especially if you follow a few basic assumptions: * The main development branch is HEAD * Merging branches are based on minor version numbers BRANCH_0_8 BRANCH_1_0 * Other branches can be used, but should be labeled well BRANCH_1_0_BUGFIX_67728 * The key to using CVS with branching really lies in consistent and discriptive use of tags, both the branching and standard types. -- Chad Walstrom [EMAIL PROTECTED] | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Get my public key, ICQ#, etc. $(mailx -s 'get info' [EMAIL PROTECTED]) msg00749/pgp0.pgp Description: PGP signature
Re: my attachment code, plus attachments in general (really new release)
I'm not sure that I agree. When I asked people on this list about making changes to the CVS, I was told to post my changes and someone would look 'em over and put them into the CVS. I couldn't find anybody to give me CVS write access since the maintainer was too busy. So let's not just toss out everything that fell through the cracks because the maintainer was too busy. Jon, I understand your concern, and I can perfectly understand your frustration at doing a significant amount of valuable work but not getting it into the tree. But in my view, Shantonu is right ... we've had essentially two years of development that has not seen a release. I think the current CVS work has been relatively well tested, so I'd rather do a release ASAP and then fold in your work (by giving you CVS access, of course). I don't even think this is that incompatible ... from what I've seen, the best thing to do would be to create a release branch and do any release engineering work on it and put your work on the head. --Ken
Weird glitch somewhere
Hey, all. I'm using nmh 1.0.4 on Mac OS X, and I'm trying to duplicate the functionality I had on my Linux box. I'm using fetchmail 5.8.17 and procmail 3.21 and somewhere along the lines, something is different. Now any messages that come in and get delivered with rcvstore have '^M' at the ends of the lines, and it messes up scan, show, repl, forw, etc. The only thing I've seen so far is that fetchmail has this when I run fetchmail --version: Carriage-return stripping is disabled (stripcr off). Carriage-return forcing is disabled (forcecr off). Might this be the cause? Sorry to bring in a bunch of non-nmh variables. I thought someone might have a similar setup... Zac
A Modest nmh Proposal
Okay, my reading of the rough consensus of the messages I've seen is, Yes, do something, dammit. Here's what I think we should do: - We should wait for Dan to say something. I just checked my exmh address book, and the last message I ever saw from Dan was July 31st. So I'm not even sure he's still around. But nevertheless, I feel it's only right to see if he's got something to say. He may say, Hey, I'm still going to do something with nmh. If that's the case, then I guess we'll start another discussion about the future of nmh. But let's assume that Dan either say, Hey, I'm too busy, go for it, or he doesn't respond. January 1st has been suggested by a couple of people, and it sounds as good as a date as any to set as a deadline, so I think that's how long we should wait. - At this point, I become the Grand High Poobah of nmh. But seriously, I think that someone should be Project Lead, Head Guy, Lead Asshole, _something_ ... and I'm willing to do it. If someone ELSE wants to do it, then step up; I'll vote for 'ya. But I don't want things bogging down in some nmh committee ... I think it's time for one guy to kick some MUA ass and get nmh out the door. If no one objects, I'll do it. If someone does, then I'll let him/her step up to the mhicrophone. - We keep the the CVS server at mhost.com, assuming Doug is amemable to the current situation. It's there, it works, and I don't want things to get delayed anymore by a server move. Judging by Doug's email, I think that past issues about Doug being too busy to assist with server things have mostly been resolved. Maybe if Doug gets too busy, we'll think about moving it. I _would_ like to do off-site backups of the CVS repository, but assuming everything goes through, I'll work that off-line with Doug. - At this point, we create a release branch. We give Jon a CVS account and let him start committing work to his heart's content. Me, Shantonu, and maybe a few others do whatever release engineering work we need to do get nmh 2.0 (or whatever we call it, but I think nmh 2.0 is a good version number). I'm thinking a couple of beta release cycles and then a new final release, maybe by the end of January. - We continue to have new releases every so often .. if we have a continual stream of new features, I think a release every three months isn't out of the question. I continue in my role of nmh Dictator and usher in a New Age of Enlightened Mail Reading. So, what does everyone think? --Ken
Re: A Modest nmh Proposal
Ken Hornstein [EMAIL PROTECTED] wrote: At this point, I become the Grand High Poobah of nmh. Great, politics already. :/ I _would_ like to do off-site backups of the CVS repository, but assuming everything goes through, I'll work that off-line with Doug. Definately... It would be a shame to loose all the history. One nice way to accomplish this would be to allow cvsup access, then anyone can have a full mirror of the cvs repository. At this point, we create a release branch. I don't see a need for a branch at this point. All the work will be moving along the same path and thus can be done on HEAD. Me, Shantonu, and maybe a few others do whatever release engineering work we need to do get nmh 2.0 (or whatever we call it, but I think nmh 2.0 is a good version number). I'm thinking a couple of beta release cycles and then a new final release, maybe by the end of January. I am not sure the changes thus far warrant bumping the major version number, but in the scheme of things I don't think it is really worth arguing over so whatever everyone else thinks. Aiming for the end of Janurary sounds reasonable enough to get all the patches tested and commited. -- Doug Porter [EMAIL PROTECTED]
problem with fetchmail/procmail/rcvstore fixed
Sorry for barging in. Seems the fetchmail versions were different. Now I have it explicitly stripping CRs from incoming mail, and everything works nicely. Zac
Re: A Modest nmh Proposal
Ken Hornstein wrote: Part of my motivation for a 2.0 release is to draw attention back to I'd say it still only warrants a 1.1. There are insufficient new features added or changed functionality. Leave 2.0 for a major rewrite. I think bumping a version number simply to draw attention to a realease is a bit of a lie. The nmh code is still quite a mess. I'd rather see 2.0 be a nice clean release. Why not kick this out as 1.1.0 (with a 1.1.1 coming soon after with the additional patches from the archives) and instead write up a roadmap of what 2.0 should do? As I said earlier, I'm happy to keep hosting the code. I'll get Ken set up with a cvs account this evening (around midday or morning for you folks in the states). That brings the total of CVS accounts up to 6 at the moment, not counting me, but I'd like to give until January to hear from the remaining folks to say if they still are around. Here's the list of accounts right now: Ken Hornstein Dan Harkless Dan Winship Kimmo Suominen Ruud de Rooij Shantonu Sen The last two are currently active on the list, so unless you say close my account I'll leave it. The rest I'll give until 1 January as suggested, and then do an account cleanup (ie: get rid of 'em). -- Doug Morris Morris Communications Computer Services, Inc. http://www.mhost.com/
Re: A Modest nmh Proposal
I'd say it still only warrants a 1.1. There are insufficient new features added or changed functionality. Leave 2.0 for a major rewrite. Are you sure? Have you looked at the changes? There was a whole lot of cleaning up that was done, and I don't think the security stuff was insignificant either (but I'm obviously biased). I think bumping a version number simply to draw attention to a realease is a bit of a lie. The nmh code is still quite a mess. I'd rather see 2.0 be a nice clean release. Why not kick this out as 1.1.0 (with a 1.1.1 coming soon after with the additional patches from the archives) and instead write up a roadmap of what 2.0 should do? I'll think about it; I don't have really strong feelings that this should be 2.0, but enough people disagree with this one that maybe it's the wrong call. I guess I'll save my energy for my first controversial CVS commit that I know is going to get people screaming :-) --Ken
Re: A Modest nmh Proposal
On Sat, 8 Dec 2001, Ken Hornstein wrote:
I'd say it still only warrants a 1.1. There are insufficient new
features added or changed functionality. Leave 2.0 for a major
rewrite.
I will side with Doug on this (Sorry if I'm being difficult ;-( ). My
reasons are explained below.
Are you sure? Have you looked at the changes? There was a whole lot
of cleaning up that was done, and I don't think the security stuff was
insignificant either (but I'm obviously biased).
Certainly not insignificant, but we had APOP and KPOP before. While SASL
extends this to another level, it is an evolutionary change from the
previous part, not as revolutionary as may merit a doubling of release
versions. Then again, nmh-0.27 - nmh-1.0 doesn't look like there was a
complete rewrite either.
As for the changes:
34627 lines of unified diffs
-
2096 are from new config.{sub,guess} from FSF
2811 are from a regenerated configure
22802 are from man pages. There were not significant content
changes (except for a few cases). Mostly a lot of formatting
fixes and standardization
982 mts changes. Standardization of transport and SASL
2800 uip changes. SASL POP, header path changes
667 sbr changes. nothing interesting.
These statistics are wildly innacurate, because they count some CVS files,
and may not reflect that many source files were moved around. What I
really wanted to show is that you cannot infer the amount of functional
changes by diff. The man pages have some changes, true, but diff | wc
-l contributed by them should not be justification for 2.0.
Better would be to comb through the changelog, distill the differences by
category, eliminate duplicates (fixed A. oops, fixed A for real), and
rank in importance. Doublessly, SASL will be one of the biggies, but I
think there was a fair amount of SMTP transport unification (Done by
Ruud?).
I think bumping a version number simply to draw attention to a
realease is a bit of a lie. The nmh code is still quite a mess. I'd
rather see 2.0 be a nice clean release. Why not kick this out as 1.1.0
(with a 1.1.1 coming soon after with the additional patches from the
archives) and instead write up a roadmap of what 2.0 should do?
I'll think about it; I don't have really strong feelings that this should
be 2.0, but enough people disagree with this one that maybe it's the wrong
call. I guess I'll save my energy for my first controversial CVS commit
that I know is going to get people screaming :-)
I am stronly in favor of 1.1.0, followed by 1.0.5. Really, this could have
been released 1.5 years ago, and at that point, it would have been 1.0.5.
Shantonu
