From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: gnu.emacs.sources: Only sources and patches, please Date: Mon, 26 Mar 2007 08:24:13 +1000 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <87ejndezci.fsf@lion.rapttech.com.au> References: <87wt16muef.fsf@gmx.at> <87fy7t5nqu.fsf@hariken.mwolson.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1174862305 27960 80.91.229.12 (25 Mar 2007 22:38:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 25 Mar 2007 22:38:25 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Mar 26 00:38:17 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HVbLs-0006QP-AS for geh-help-gnu-emacs@m.gmane.org; Mon, 26 Mar 2007 00:38:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVbO2-0001r8-Tf for geh-help-gnu-emacs@m.gmane.org; Sun, 25 Mar 2007 17:40:30 -0500 Original-Path: shelby.stanford.edu!newshub.stanford.edu!postnews.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!sn-xt-sjc-04!sn-xt-sjc-08!sn-post-sjc-01!supernews.com!corp.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.sources,gnu.emacs.help User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux) Cancel-Lock: sha1:5mC3KsSb4UL4CyvBBg6vqm2IUvw= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 54 Original-Xref: shelby.stanford.edu gnu.emacs.sources:11766 gnu.emacs.help:146581 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:42185 Archived-At: Michael Olson writes: > Reiner Steib writes: > >> Hi, >> >> please let's move _discussions_ about packages posted to >> gnu-emacs-sources/gnu.emacs.sources to help-gnu-emacs/gnu.emacs.help >> >> gnu-emacs-sources is intended only for code and patches... > > I don't like this convention. The name "gnu.emacs.help" does not > particularly suggest to me that discussion for posts to > gnu.emacs.sources should be followed up there -- that is, I have no > certainty that program authors who post to .sources are also > subscribed to .help, and little hope that they can find replies to > their code submissions in .help, due to the relatively high volume of > that group. > > Also, even if I am totally mistaken about my other assertions, I think > if replies to posts in .sources include new/revised source code, it is > disingenuous to tell people to send them to a different list. > > If we must insist on different destinations for source and comments, > how about a separate, low-volume list (measured relative to > gnu.emacs.help) called gnu.emacs.sources.discuss? > > -- My understanding is that this group/list is for sources rather than discussion. However, I think patches are probably OK, though its probably better to send them directly to the author to prevent multiple patches for similar bugs/features and leave it to the author to apply. What I think definitely needs to be avoided is long threads debating particular issues relating to a package, especially if that discussion moves away from specific code issues to more philosophical ones. Part of the reason I have this perspective is that a number of places I know of archive the contents of this list and it can be a handy resource to find code. If it ends up with lots of discussion posts and the ratio of code to posts drops, it would lose part of this stremgth. I don't think another list is a good idea. Discussion of package/code issues could be done in g.e.h and in fact would possibly be a benefit there. Another list would just dilute things further. Of course, just my 2 cents worth. If the general consensus is different, I have no problem with following that. Tim -- tcross (at) rapttech dot com dot au