From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: recent changes to org files Date: Tue, 23 Oct 2007 13:59:53 +0200 Message-ID: <863aw26nye.fsf@lola.quinscape.zz> References: <8D11CC21-71C6-4BCE-ACBC-090E429E311A@science.uva.nl> <86k5pe6t4e.fsf@lola.quinscape.zz> <1100BA17-7426-4C73-9EF0-FF90C1859B47@gmail.com> <86bqaq6pza.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1193140828 6546 80.91.229.12 (23 Oct 2007 12:00:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2007 12:00:28 +0000 (UTC) Cc: John Wiegley , Stefan Monnier , Glenn Morris , emacs-devel@gnu.org To: Carsten Dominik Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 23 14:00:28 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IkIQl-0000Ex-4O for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2007 14:00:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IkIQc-0002av-56 for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2007 08:00:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IkIQT-0002Wh-Vn for emacs-devel@gnu.org; Tue, 23 Oct 2007 08:00:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IkIQT-0002Ux-1m for emacs-devel@gnu.org; Tue, 23 Oct 2007 08:00:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IkIQS-0002Ua-8V for emacs-devel@gnu.org; Tue, 23 Oct 2007 08:00:00 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IkIQR-0008H9-EP for emacs-devel@gnu.org; Tue, 23 Oct 2007 07:59:59 -0400 Original-Received: from quinscape.de (dslnet.212-29-44.ip210.dokom.de [212.29.44.210] (may be forged)) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id NAA15645 for ; Tue, 23 Oct 2007 13:59:50 +0200 X-Delivered-To: Original-Received: (qmail 19107 invoked from network); 23 Oct 2007 11:59:54 -0000 Original-Received: from localhost (quinx.quinscape.de [127.0.0.1]) by quinx.quinscape.de (AvMailGate-2.1.3-2) id 19102-CEGEmz; Di, 23 Okt 2007 13:59:54 +0200 (CEST) Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 23 Oct 2007 11:59:54 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 1EAEAE1C6E; Tue, 23 Oct 2007 13:59:53 +0200 (CEST) In-Reply-To: (Carsten Dominik's message of "Tue\, 23 Oct 2007 13\:34\:44 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.3-2; AVE: 7.6.0.27; VDF: 7.0.0.121; host: quinx) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:81556 Archived-At: Carsten Dominik writes: > Well, checking in a patch with changes would not lead to a conflict > in an area that I have not modified. It will lead to a successful merge. Nobody said that synchronization requires no diligence at all. > So just checking in patches will not remove a bug that has (clearly > by accident) been introduced in one of those clean-up operations > where many files are are modified in order to implement a rule like > "don't use next-line in lisp programs". These changes typically > affect many files, and it is impossible for the developer who does > the change to be sure in all cases that he has done the right thing. And it is pretty impossible for the developer to figure out maintainers for every single file, mail them all, keep book of who replies within what time frame, and then react accordingly. > The only way to make sure is to run these changes by the maintainer. And the most reliable way to do this is to check them in, with a proper log entry. > In that past, that has happened sometimes: I get an email with > proposed changes, with the request to check them before they are > committed. For example, Stefan has been doing things like this, and > I appreciate his comments and additions, and the way he handles it, > a lot. Single-line purported bugfixes are not really additions or comments. >> If some code is in violation of the Emacs development guidelines, >> the reason should be documented so that people _know_ about it and >> leave it alone. Silently reverting the change in a manner that >> looks like an accident will not achieve this. > > Yes. Of course I only reverted the change "by accident" without an > accompanying change log. Still, I am maintaining that the copy I > work on every day is the most reliable one, and that any significant > changes should be run by me. That means that improvements by several people must not be combined, and that the results of uncombined changes have to compete on overall reliability. I can't see this. There is no competition going on. Instead, every contributor strives to improve reliability in the code he is overseeing. >> Basically you are asking that nothing, including bug fixes, may be >> committed to org-mode except by yourself. > > No, this is not correct. I request that I changes are run by me > first, Which means that they must not be committed. So my description _is_ correct. Whether you yourself do the actual work of committing or someone does it on your request is a technical detail. The sum of it all is that you don't accept anybody else to take responsibility for committing anything to org-mode. And that means that there is no sense in org-mode being maintained inside of Emacs' CVS if no changes must ever be introduced that don't simultaneously are checked into your personal CVS. >> Being a maintainer does not mean that nobody else may do work on >> the code. It means that people in general respect you having the >> last word. But it is the last, not the only word. > > Exactly my words. Your words don't match your proposed way of working. Emacs maintainance quite often means bulk changes: new interfaces and semantics are introduced, and things like the multitty changes and the unicode changes necessitate global work (as do added bytecompiler warnings). It is not feasible to do the update work only after figuring out prospective maintainers for every file. The only hope to get things like this done is to do the changes and let the maintainers check for them. And merge time is certainly an important point of time for checking it (though regularly checking for diffs in that area is not amiss either for a maintainer actually interested in his code). If your workflow does not permit fixes to be applied to Emacs CVS, the only sane solution short of adjusting your workflow is to remove org-mode from Emacs CVS. Only in that manner can it be assured that bug fixes and interface changes and other things can actually persist. -- David Kastrup