From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/68803 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus branches and sync with Emacs Date: Wed, 22 Jul 2009 10:32:48 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87k520n36n.fsf@lifelogs.com> References: <87eisdn3ng.fsf@marauder.physik.uni-ulm.de> <87skgri803.fsf@lifelogs.com> <871vobdxpu.fsf@stupidchicken.com> <87eisbw0gf.fsf@marauder.physik.uni-ulm.de> <87zlayf26p.fsf@lifelogs.com> <87tz16t09n.fsf@marauder.physik.uni-ulm.de> <87zlaxol4b.fsf@lifelogs.com> <87ab2xbw9r.fsf@ID-24456.user.uni-berlin.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: ger.gmane.org 1248276839 13731 80.91.229.12 (22 Jul 2009 15:33:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jul 2009 15:33:59 +0000 (UTC) Cc: To: Christoph Conrad Original-X-From: ding-owner+M17223@lists.math.uh.edu Wed Jul 22 17:33:52 2009 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1MTdpF-0003qn-DS for ding-account@gmane.org; Wed, 22 Jul 2009 17:33:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1MTdos-0007JM-V5; Wed, 22 Jul 2009 10:33:27 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1MTdor-0007J4-JH for ding@lists.math.uh.edu; Wed, 22 Jul 2009 10:33:25 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1MTdoq-0006PL-2X for ding@lists.math.uh.edu; Wed, 22 Jul 2009 10:33:25 -0500 Original-Received: from chirelay1o.jumptrading.com ([38.98.147.153] helo=chirelay1.jumptrading.com) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1MTdpO-0001tL-00 for ; Wed, 22 Jul 2009 17:33:58 +0200 Original-Received: from chirelay1.jumptrading.com (unknown [127.0.0.1]) by chirelay1.jumptrading.com (Symantec Mail Security) with ESMTP id BFE45320031 for ; Wed, 22 Jul 2009 10:31:22 -0500 (CDT) X-AuditID: 26629395-a5f15bb0000078af-1d-4a6730caddd8 Original-Received: from chiexchange02.w2k.jumptrading.com (unknown [38.98.147.140]) by chirelay1.jumptrading.com (Symantec Mail Security) with ESMTP id 89ECD2DC003 for ; Wed, 22 Jul 2009 10:31:22 -0500 (CDT) Original-Received: from internalsmtp.w2k.jumptrading.com (10.2.4.29) by chiexchange02.w2k.jumptrading.com (10.2.4.71) with Microsoft SMTP Server id 8.1.291.1; Wed, 22 Jul 2009 10:32:49 -0500 Original-Received: from tzlatanov-ubuntu-desktop.jumptrading.com ([10.2.21.147]) by internalsmtp.w2k.jumptrading.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jul 2009 10:32:49 -0500 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" In-Reply-To: <87ab2xbw9r.fsf@ID-24456.user.uni-berlin.de> (Christoph Conrad's message of "Tue, 21 Jul 2009 22:43:35 +0200") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux) X-OriginalArrivalTime: 22 Jul 2009 15:32:49.0768 (UTC) FILETIME=[ABAD9680:01CA0AE1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.3 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:68803 Archived-At: On Tue, 21 Jul 2009 22:43:35 +0200 Christoph Conrad wrote: CC> Hi Ted, >> so I think stability is supposed to be an exception, at least when >> that was written. CC> When trunk CVS gnus is meant here: i am using it for several years now, CC> and for a very long time it has been stable. I meant stability in the sense of fewer updates to stabilize the source code (which reminds me of the quip that biology has a word for "stable" and it's "dead"). Perhaps the right word was "quiescense" :) I agree the Gnus trunk has been very reliable since I can remember, but my point is that if I want to put in a bleeding-edge feature I shouldn't have to wait for the next release. There's definitely an implicit agreement that no such features should be pushed if they break current setups or endanger user data, especially if they are on by default. I am not implying otherwise. Ted