- The new procmail development tree is available through anonymous SVN
(I can recommend using SVK though) via:
svn://svn.cuci.nl/public/procmail/trunk
[snip]
As of now, I openly invite anyone to download the current version, test it,
send in complaints/bug-reports and/or provide me with patches you have
been saving up (preferably relative to the SVN version).
Ok I finally got some time to take a look at it. It's off to a good start. I
have a few suggestions.
1. I strongly encourage you NOT to use version 3.23[pre]. I would start with
3.40 or 3.50. You want to indicate a break; development isn't just picking up
where it left off - especially years later.
2. Along these lines, I can't imagine you think you can fool the public into
thinking time has stopped. :-)
The HISTORY file lists:
2001/09/13: v3.23pre
...
Yet the svn log indicates "root" made the modification last month.
r1072 | root | 2005-10-31 20:44:56 -0500 (Mon, 31 Oct 2005) | 71 lines
Come on, be honest! Even if v3.23 did start development back in 2001, having
it sit on the shelf for four years and then resuming it w/o indicating the
lapse in time isn't really an accurate representation of history is it? :-)
Also, a username would be better than "root" but you know that... *grin*
BTW, you'll want to add a HISTORY entry along the lines of "Converted
repository from CVS/RCS to SVN". It's a change worth noting don't you think?
3. You've picked up some of the patches made by the public over the years.
There's more in:
http://ftp.debian.org/debian/pool/main/p/procmail/procmail_3.22-11.diff.gz
The ChangeLog patch in this diff explains what most of them are. Some patches,
like the path ones, you probably aren't interested in. When I get time, I'll
try to look up the patches RedHat and SuSE have applied to procmail over the
years and see if there's additional ones that should be added. Anyway, you
should incorporate as many of these patches as you can - some bugs have been
fixed.
4. Lastly, I really don't want to start a flame war, so I'll just reiterate,
this is a *suggestion*. IMHO, to facilitate people reviewing and contributing
code, it _might_ be prudent to change the indent style to be more readable. If
development is to start up again, now might be a good time to use indent(1) (or
whatever) and reformat it.
I realize historically the code is tight and has always been this way. There
are some arguments not to reformat it such as realigning comments to their
respective areas, but this penalty might be worth it to make procmail more
accessible. Of course, I'm ASSuming that the current code format is or will be
a turn off to the public w.r.t. coding.
Anyway, like I said, this is a suggestion. If the plan for procmail is to
start a new 4.0 version, then obviously reformatting the current code now
doesn't make sense. If on the otherhand, the 3.x development plans to
continue, then now might be a good time for it.
Well that's all for now. It is good to see all the procmail suggestions coming
in and Funck's summary of all the ideas was great. They should be put in a
FUTURE/TODO file and added to the repository.
$.02,
-Sam
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail