From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames. Date: Thu, 02 Aug 2012 14:56:16 +0900 Message-ID: <87a9ydbzwf.fsf@uwakimon.sk.tsukuba.ac.jp> References: <50191B54.2070705@yandex.ru> <5019FE2D.2060005@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1343886990 29549 80.91.229.3 (2 Aug 2012 05:56:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2012 05:56:30 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 02 07:56:30 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SwoOc-00056j-Cl for ged-emacs-devel@m.gmane.org; Thu, 02 Aug 2012 07:56:30 +0200 Original-Received: from localhost ([::1]:50221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwoOb-00041j-Pz for ged-emacs-devel@m.gmane.org; Thu, 02 Aug 2012 01:56:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwoOZ-000412-1T for emacs-devel@gnu.org; Thu, 02 Aug 2012 01:56:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwoOY-0003dm-1r for emacs-devel@gnu.org; Thu, 02 Aug 2012 01:56:26 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:58670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwoOX-0003at-Hx for emacs-devel@gnu.org; Thu, 02 Aug 2012 01:56:25 -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 4A8DC3FA073C; Thu, 2 Aug 2012 14:56:17 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 11CEE1A3B72; Thu, 2 Aug 2012 14:56:17 +0900 (JST) In-Reply-To: <5019FE2D.2060005@yandex.ru> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta31) "ginger" b4715fcbe001 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:152106 Archived-At: Dmitry Antipov writes: > Look at concurrency branch. Everyone agrees that this is an > interesting and useful feature, I don't think that's true. Emacs needs concurrency, it's true. It's not obvious that Emacs Lisp does. Dynamic scope + concurrency = nightmare. You're not going to get RMS (or most Emacs developers) to give up the former, so the latter is going to need to be seriously restricted (eg, a GIL). You're welcome to have a different opinion, and obviously several people disagree with my assessment. I'm not going to argue that point. But I suggest to you that one reason why many people who might otherwise be interested in the concurrency branch don't bother with it is that they agree with me, not you. > but no one wants to handle an endless merging efforts. If we had > the same amount of developers as involved in Linux kernel, It's not the number of developers, it's the customary discipline in the community. SXEmacs has a far smaller number of developers than GNU Emacs does, but they branch like crazy and seem to love it. Many projects do. Merging really isn't that bad if your architecture is designed for it and your workflow adapted to it. It's annoying, true, but far less so than writing tests, or even documentation. Not to say I don't understand your pain, just that Emacs *can* have an effective branching-based workflow if Emacs wants it. bzr is certainly adequate for such a workflow. However, bzr was selected partly because certain folks with veto power didn't want that kind of workflow for themselves, so making a change is going to take a while. For you personally, why don't you talk to Miles (aka Mr. Lexbind) and Eli (aka Mr. BIDI) and see if they have some hints for maintaining one's own enthusiasm for working on a long-lived branch? After all, they did it successfully! And talk to Eric Ludlam and friends and see if CEDET has support for the kind of refactoring that you may need to do, and the Bazaar develoeprs to see how they handle what git calls re-re-re.