Re: Rmail-mbox branch

[Stefan Monnier]

> Only that there will very likely be a raft of messages to the affect
> of "What the fuck happened to Rmail..."  My oft stated opinion is that
> we should commit the Rmail/mbox code immediately after a release thus
> giving us the maximum amount of time to fix Rmail/mbox bugs.
> Admittedly Rmail/mbox has been less buggy than I had expected it would
> be in the week or so that I've been using it.  Richard has found a
> couple of bugs, as have I, one of which was the same bug.  So for me
> the answer to your question depends on when the next release of Emacs
> is targeted.  If it is imminent, like in weeks or a few months, then I
> would advise waiting.  If it won't happen for many months, then now is
> as good a time as any.

> The only area I know is incomplete is confirming that spam filtering
> is up to date.  I think it is but there is a few commits to
> Rmail/babyl that I'm not sure are relevant to Rmail/mbox.

> Also, there is one suggestion that Richard made that will facilitate
> automatic conversion of Babyl formatted file to mbox format.  This one
> should probably be completed before we make the switch.

Installing pmail on the trunk as it is now only makes/made sense on the
assumption that it's temporary and will be moved to rmail before
the release.  "The" release here is 23, since the trunk holds the code for
Emacs-23.
Emacs-23 is in feature freeze but hasn't started pretesting.
You could call it something like `alpha' or `beta' quality.

The sooner you can move Pmail to Rmail the better (it's the one
remaining feature that hasn't yet been installed, so it's an exception
to the feature freeze).

I don't use Rmail myself, so I can't really comment concretely, but as
soon as Pmail's feature-set is equal to (or a superset of) Rmail and
those features are mostly working, we should move Pmail to Rmail.
>From what you say, it seems that we're really close now.


        Stefan