From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: [rmail-mbox-branch]: expunge Date: Fri, 24 Sep 2004 11:23:58 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <1096006177.432792.29828.nullmailer@Update.UU.SE> <1096014084.739640.30529.nullmailer@Update.UU.SE> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096017931 25844 80.91.229.6 (24 Sep 2004 09:25:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 24 Sep 2004 09:25:31 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 24 11:25:17 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CAmKL-0002Cd-00 for ; Fri, 24 Sep 2004 11:25:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CAmQP-0002WT-PU for ged-emacs-devel@m.gmane.org; Fri, 24 Sep 2004 05:31:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CAmPi-0002ID-JV for emacs-devel@gnu.org; Fri, 24 Sep 2004 05:30:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CAmPg-0002HW-Go for emacs-devel@gnu.org; Fri, 24 Sep 2004 05:30:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CAmPg-0002HJ-9w for emacs-devel@gnu.org; Fri, 24 Sep 2004 05:30:48 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1CAmJ4-0004eI-RE for emacs-devel@gnu.org; Fri, 24 Sep 2004 05:23:59 -0400 Original-Received: (qmail 24131 invoked from network); 24 Sep 2004 09:23:57 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 24 Sep 2004 09:23:57 -0000 Original-To: "Alfred M. Szmidt" In-Reply-To: <1096014084.739640.30529.nullmailer@Update.UU.SE> (Alfred M. Szmidt's message of "Fri, 24 Sep 2004 10:21:24 +0200") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27531 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27531 "Alfred M. Szmidt" writes: > > [I wouldn't recommened merging this back into trunk by a long > > shot, it is far to broken] > > It seems that the new rmail-mbox-branch code is quite far from > 'production quality' so IMHO it is not ready for inclusion in 21.4. > > I'm kinda curious if anyone actually used the rmail-mbox-branch > before... I was hoping that it would only contain minor bugs, but it > contains some quite serious bugs (eating my mail is serious, not even > being able to run it is serious since it means that it hasn't been > even tested!). > > Do we really need to postpone the release of 21.4 just for this one > feature? Can't it wait until 22.1 ? > > To me as a user of rmail, I would really prefer it to wait for 22.1. > Right now it is far to broken, if there were more people that could > actualy help out and test it and send patches, then just maybe. Even > if I said that one shouldn't merge that branch into trunk, maybe that > would be one good way to force people who use rmail to actually use it > and fix it right now and get it ready for 21.4; but I don't know what > the current status of the tree is right now. > > And anyway, the babyl format has been used for such a long time that > postponing this feature until 22.1, 23.1 or even 100.1 won't do any > harm anyway. > > Those are just my opionions as a user of rmail and emacs; feel free to > ignore them completely. I think your opinion (based on actual experience with using the code) is very important (to me at least :-) as it clearly expresses the concern I have had (and expressed) for some time regarding the mbox branch: Unless we are 99.9% confident that the new mbox-rmail works as good the the current babyl-rmail, releasing 21.4 with a broken/deficient mbox-rmail would be a disaster! Your findings indicates to me that we are far from those 99.9% ... And as you say, babyl has done the job fine for MANY years, so what's wrong using it a little longer (1-2 years isn't long in emacs development :-) -- Kim F. Storm http://www.cua.dk