From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: smtp crap Date: Tue, 11 Oct 2011 16:34:00 +1100 Message-ID: References: <8739f4kzp3.fsf@catnip.gol.com> <87ipo0p1bc.fsf@stupidchicken.com> <58C87CB9F44943A7BBE78F2D6B62A850@us.oracle.com> <8762jwfjsj.fsf@catnip.gol.com> <292D655E-5979-4A75-89F3-58031CECA981@mit.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1318311254 14844 80.91.229.12 (11 Oct 2011 05:34:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 11 Oct 2011 05:34:14 +0000 (UTC) Cc: Emacs devel , Miles Bader To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 11 07:34:08 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RDUye-0002dV-4a for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2011 07:34:08 +0200 Original-Received: from localhost ([::1]:53104 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDUyd-0001t1-84 for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2011 01:34:07 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDUya-0001sr-Vj for emacs-devel@gnu.org; Tue, 11 Oct 2011 01:34:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDUyZ-00056s-O6 for emacs-devel@gnu.org; Tue, 11 Oct 2011 01:34:04 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:62037) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDUyY-00056S-4b; Tue, 11 Oct 2011 01:34:02 -0400 Original-Received: by iaen33 with SMTP id n33so10861031iae.0 for ; Mon, 10 Oct 2011 22:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5zbW1Tw7RUqGac1hZ1dy+Kx/ViKe1Czd8gysWnVUIhA=; b=YgpwS9gCdv3qC2UpJZQfP6GQD8cj+qyvtztJjiXLKFp0LjWDfUOguhzLXaV//n/Oy8 9/uytzP+xltC+m+eVmaEuNG0Xk+YfHZla2ksZsHzkzoqkHzMiZ6ZV/7I7BYyXFKobiqU K1HYwnHdl6mjcKqe4ZPQOhXX1simS78ZojKyo= Original-Received: by 10.231.20.147 with SMTP id f19mr6344606ibb.13.1318311240442; Mon, 10 Oct 2011 22:34:00 -0700 (PDT) Original-Received: by 10.231.12.67 with HTTP; Mon, 10 Oct 2011 22:34:00 -0700 (PDT) In-Reply-To: <292D655E-5979-4A75-89F3-58031CECA981@mit.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:144867 Archived-At: On Tue, Oct 11, 2011 at 3:41 PM, chad wrote: > > On Oct 10, 2011, at 9:20 PM, Miles Bader wrote: >> So absent any data showing the new method would (or at least _might_) >> improve things, isn't this change in behavior kind of dubious...? > > > In one or two of the previous conversations on this topic, we talked > about the cases where it does improve things: it is common for a > machine to have a local sendmail (-doppelg=E4nger) that silently eats > mail. > > I have personally seen (several years ago, at MIT) a large number of > report-emacs-bug messages that ended up stranded on such a machine, > and the user had no reasonable way of knowing that the message had not > been sent (as far as they could tell, it *had* been sent). =A0I have no > idea how common this sort of configuration is today, but when we > discussed it before, it seemed that at least 2 or 3 common, popular > GNU/Linux distributions were likely to fall into this or similar > problem configurations. > The main argument supporting the change in default behaviour for mail was that the mail environment has evolved, particularly with the introduction of 'mobile devices' and apparently increasing incidence of local MTAs not being configured or being incorrectly configured etc. This all seemed fair enough. However, the devil is always in the details and soon we began to encounter complications, particularly with respect to emacs' bug reporting facilities and being able to use these facilities when running emacs with the -Q switch. More and more complicated solutions appear to be pushed forward and it would seem many are less than satisfied with the results so far. I think we may be over complicating matters and need to re-focus on what we really are trying to do. Some time back, it was suggested that perhaps we really need to reconsider how emacs bug reporting processes should work. If the email environment has evolved as has been suggested, then perhaps what we really need to do is re-think how emacs supports the submission of bug reports. For example, if it did not rely solely on email, we could remove the hacks which have been proposed to enable bug reports when running -Q and we could eliminate the whole issue of emacs users being forced to configure emacs for mail simply to send a bug report. Those who want to use emacs for email can and they will have the motivation to configure it. Those who don't will not have to and won't get frustrated by emacs forcing them to. We can avoid the overly complex configuration wizard,. which I suspect will be very difficult to get right for all platforms and will be a source of bugs for a long time. I would suggest that whatever changes are made to bug reporting that email remain as an option which users can choose if they so desire. Apart from that, I would suggest opening up the discussion to see what ideas people may have. Initial suggestions to re-examine how we do bug reporting were largely rejected. However, perhaps after the issues raised relating to the use of email, maybe there is increased willingness to re-consider this issue. Tim --=20 Tim Cross Phone: 0428 212 217