From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/80432 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: smtp crap Date: Thu, 27 Oct 2011 11:51:01 +0900 Message-ID: <87y5w7p2p6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <8739f4kzp3.fsf@catnip.gol.com> <87ipo0p1bc.fsf@stupidchicken.com> <58C87CB9F44943A7BBE78F2D6B62A850@us.oracle.com> <5997613E240C402C877A76C688773E65@us.oracle.com> <4D117A6B-0C4E-4F13-AC0E-C64DAB66C996@mit.edu> <447111A2EC694399973999C249891686@us.oracle.com> <1C9CC457-A5D9-40F4-9D26-7A4C37829042@MIT.EDU> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1319684734 3637 80.91.229.12 (27 Oct 2011 03:05:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 27 Oct 2011 03:05:34 +0000 (UTC) Cc: ding@gnus.org, Drew Adams , 'Emacs devel' To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 27 05:05:29 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 1RJGHZ-0001Nu-G7 for ged-emacs-devel@m.gmane.org; Thu, 27 Oct 2011 05:05:29 +0200 Original-Received: from localhost ([::1]:37029 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJGHW-0003wm-Km for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2011 23:05:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJG3e-0002rK-EB for emacs-devel@gnu.org; Wed, 26 Oct 2011 22:51:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJG3c-0005CO-Qv for emacs-devel@gnu.org; Wed, 26 Oct 2011 22:51:06 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:58712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJG3c-0005CC-60 for emacs-devel@gnu.org; Wed, 26 Oct 2011 22:51:04 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id CAEF63FA061F; Thu, 27 Oct 2011 11:51:01 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C3B27137A7B; Thu, 27 Oct 2011 11:51:01 +0900 (JST) In-Reply-To: <1C9CC457-A5D9-40F4-9D26-7A4C37829042@MIT.EDU> X-Mailer: VM 8.2.0a1 under 21.5 (beta31) "ginger" 76fad4a87f68 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 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:145617 gmane.emacs.gnus.general:80432 Archived-At: chad writes: > > On Oct 26, 2011, at 3:32 PM, Drew Adams wrote: > > >>> This is nothing but a regression - reporting a bug with `emacs > >>> -Q' has never been a problem in past releases. Why burden > >>> and confuse users now? > >> > >> I have personally seen dozens, of emacs bug reports sitting > >> stuck in local mail queues, [...]. > > > > Yes, that is undesirable. > > Undesirable, well know, and obviously the opposite of ``has never been > a problem in the past'', as you knew before you wrote those words. It > also pretty clearly answers the question ``Why burden and confuse > users now?''. Incredible! The problem is clearly in the bug report instructions, which should say something like: Note that emacs *may* be able to send mail on some systems, but if you haven't tested sending mail from Emacs[*], it is best to compose your report using M-x report-emacs-bug, and save that buffer to a file. Then read it into your usual mail agent (or attach it as a file to your mail). If you do send the bug report directly via C-c C-c, please double check that your return address is correct before doing so. [*] A reference here to an Info node about configuring mail for Emacs *might* be appropriate. But then again, it might not. and - It is best if you provide a recipe starting from "emacs -Q", with a minimum number of external libraries etc needed to demonstrate the bug. ("emacs -Q" is relatively unlikely to be able to send mail, and may not even be able to report failures. If you use Emacs as your MUA and have not tested mail under "emacs -Q", you should save the bug report buffer to a file and send it via a normal emacs process, ie, without "-Q".) The blurb in the bug report buffer should repeat the paragraph starting with "Note". The "save and attach" dance really is not a lot of trouble compared to the rest of the bug reporting process. Or perhaps those notices are already present, and the problem is in the deplorable deterioration of the reading level of some users. But users who don't pay attention to those notices are hardly likely to be able *and* willing to configure mail to send one bug report.[1] > > The solution is to simply _mention_ in the bug-report > > instructions that "IF you have no mail client and IF you have not > > yet configured Emacs itself as a mailer, THEN invoke `M-x XYZ' to > > so configure it.", where XYZ is a command that leads you down > > whatever configuration garden path is required. Drew, I'm shocked. This is no time to be configuring mail, which is a process fraught with fear, uncertainty, and doubt. The real solution (which bears repeating, despite the resistance it has encountered from some quarters) is to try to submit initial reports via a reliable point-to-point protocol (eg, HTTP) that will either succeed or fail immediately, then fall back to email. (The fact that HTTP can fail due to lack of a configured proxy etc is immaterial; what's important is that the user is informed of the failure, which a store-and-forward protocol like mail cannot do.) If "bug reports in email queues not configured for relay to remote hosts" is on the increase, it is almost certainly due to users' familiarity with bug report processes that do not use mail for transport, whose expectation is that the bug report system knows what it's doing. > Seems like a pretty poor default to me. YMMV. Asking anyone except maybe Eric Allman to configure mail in the middle of the bug report process is about as poor a default as I can imagine. Footnotes: [1] I'll concede that the word "deplorable" is unfair to many users, particularly those who use English as a second language. But if reading the bug report instructions is difficult in a second language, how can mail configuration instructions be any easier?