From: Kent Landfield (kent@hypermail.org)
Date: Wed Oct 20 1999 - 21:09:45 CDT
There are a couple parts to this message.
- Note of the work done in the last few days,
- Revised general release checklist
- Questions concerning outstanding issues
Please read and respond.
================= Recent Work Status ===================
In the last couple days there have been some new fixes added to
the baseline that cleaned up a couple problems and sped things
up quite nicely.
>From the Changelog:
-------------------
Scott Rose <srose@direct.ca> (October 20, 1999)
- When a URL has trailing punctuation, it is almost certainly not part of
the URL. This version of parseurl() therefore excludes trailing
punctuation from URLs it finds.
- If the content-description of a message was empty, and at the end of a
line, the link to the associated attachment was anchored on null text.
Fixed to assure the text is anchored on the filename in the generated HTML.
Scott Rose <srose@direct.ca> (October 19, 1999)
- Added contrib/canonicalize.pl
Comparing two archives is complicated by the fact that each message is
marked by the time at which it's archived. Attached is a script that
standardizes that date, if weakly, useful for such comparisons.
- Added contrib/hyperfeed.pl
Feed messages from an mbox into hypermail one at a time so as
to test the incremental mode of hypermail.
- The idea here is that we are zipping along through an mbox, gathering
information about a message, when we encounter a "From " line that signals
the start of the next message. A side effect is populating dp with the
date from that "From " line. In the existing code, that value is copied
into fromdate[] just before the old message is hashed, which causes it
to be associated with the previous message. This caused different output
depending on incremental or mbox updating. This patch corrects that
by moving the date copy until after the addhash function is called.
Kent (October 18, 1999)
- Updated parseurl fuction as done by Scott Rose <srose@direct.ca>
provided 25% faster processing than the existing version while
maintaining the same functionality.
-----------------
Scott's been busy. ;) Thanks Scott!
================= Recent Work Status ===================
My checklist is getting a bit smaller.
- Check for outstanding issues
- Correct any important outstanding issues
- Verify Documentation is current with all options/directives.
- Update patchlevel.h
- Regenerate a new configure
- Tag the CVS Tree
- Roll test release and if good, make it the official version
- Update Web site pages and FTP site
- Announce offical release
========== Outstanding Issues to investigate/verify/correct ============
I wanted to know what others still have outstanding that we need to
wait on before a release ? Does anyone know about the issues below
or other issues we should address before the release of 2.0 ???
-----------------------------
Date: Sat, 25 Sep 1999 11:23:48 -0600 (MDT)
From: Xual <xual@danathara.dhs.org>
Subject: Problem with incremental updates
Message-ID: <Pine.LNX.4.10.9909250157380.10946-100000@danathara.dhs.org>
Greetings,
I'm having problems with incremental updates using the msg2archive.c
program. I think the problem is thread.html(?) (index.html in my config) is
being written the same as date.html - at least I can't find any differences
between the two. Everything seems to work perfectly when using a mailbox as
input, and all other views seem to look okay using stdin, but thread view is
the same as date view.
My current setup:
RedHat 6.0
Sendmail 8.9.3
Listar 0.125a
Hypermail 2a24
Any ideas?
-----------------------------
From: "Tom von Alten" <tom_vonalten@boi.hp.com>
Subject: MIME q-p decoding
Date: Tue, 5 Oct 1999 17:40:48 -0600
Message-ID: <004101bf0f8b$0d8f5030$c9d1020f@alien-nt.boi.hp.com>
I don't suppose this just happened with 2b25, but I just happened to notice
it (while trying out Peter McCluskey's new hypetombox.pl).
8-bit characters encoded to 7-bits with MIME quoted-printable are getting
decoded back to their 8-bit source, and pushed into the HTML view of the
message in that form. I'm not sure of chapter and verse, but this isn't
legal in HTML, is it? I thought 8-bit characters were supposed to be mapped
into the &NNN; or &special-name; things for HTML.
As it is, what I see is what was intended with Netscape v4.51 on either NT
or hp-ux, but I imagine some (compliant) browsers aren't going to like the
particular mapping...
Is this an issue that should be addressed for v2?
_____________ Hewlett-Packard Computer Peripherals Bristol
Tom von Alten mailto:Tom_vonAlten@boi.hp.com
================================================================
-- Kent Landfield Phone: 1-817-545-2502 Email: kent@landfield.com http://www.landfield.com/ Email: kent@nfr.net http://www.nfr.net/ Search the Usenet FAQ Archive at http://www.faqs.org/faqs/ Search the RFC/FYI/STD/BCP Archive at http://www.faqs.org/rfcs/