From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Gnus integration (was: MH-E 7.4.4 checked in) Date: Thu, 15 Jul 2004 11:23:17 -0500 (CDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200407151623.i6FGNHq29514@raven.dms.auburn.edu> References: <1890.1089689203@newt.com> <2914-Tue13Jul2004070451+0300-eliz@gnu.org> <3589.1089692661@newt.com> <2914-Tue13Jul2004215551+0300-eliz@gnu.org> <861xjfkpgu.fsf@rumba.de.uu.net> <20040714220410.GA27263@fencepost> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1089908831 32625 80.91.224.253 (15 Jul 2004 16:27:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 15 Jul 2004 16:27:11 +0000 (UTC) Cc: kai@emptydomain.de, emacs-devel@gnu.org, storm@cua.dk, miles@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Jul 15 18:26:58 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bl94U-0006Qf-00 for ; Thu, 15 Jul 2004 18:26:58 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bl94T-0001DC-00 for ; Thu, 15 Jul 2004 18:26:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bl96x-0006Qy-DA for emacs-devel@quimby.gnus.org; Thu, 15 Jul 2004 12:29:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bl96r-0006Qt-5k for emacs-devel@gnu.org; Thu, 15 Jul 2004 12:29:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bl96o-0006Qh-Hz for emacs-devel@gnu.org; Thu, 15 Jul 2004 12:29:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bl96o-0006Qe-FR for emacs-devel@gnu.org; Thu, 15 Jul 2004 12:29:22 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Bl93r-0000NK-Ki; Thu, 15 Jul 2004 12:26:19 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i6FGQ3uE029499; Thu, 15 Jul 2004 11:26:04 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id i6FGNHq29514; Thu, 15 Jul 2004 11:23:17 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier@iro.umontreal.ca In-reply-to: (message from Stefan on 15 Jul 2004 10:45:11 -0400) 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+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:25730 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25730 Stefan Monnier wrote: I think the problem is that upstream fell out of sync. We should really try to avoid any local change that the upstream maintainer rejects, otherwise it becomes unmaintainable (I've seen it in miniature with cperl-mode.el, and I'd rather not think about what it can turn into with something like Gnus). I indeed believe that no changes (in Emacs CVS) to packages distributed with Emacs should be made without discussing them with the maintainers of those packages. People making changes to Emacs CVS usually do not worry about all the compatibility issues that the maintainers of those packages do worry about a lot, so merging changes may indeed become very non-trivial. For instance, my original proposed patch to tramp.el did not take compatibility issues into account, but, after discussing this with Kai, the patch I actually committed does, so that there should be no merging difficulties. If the maintainers of the package know of, and approve of, the change in its exact form, why should they _not_ include it in their own CVS version? In some cases, there might actually be some reasons, like philosophical differences, say about run-time loading of cl in the case of cc-mode, but even in those cases, I believe maintainers should be aware of the changes made to Emacs CVS. Sincerely, Luc.