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: source repository Date: Thu, 05 Jul 2007 10:02:50 +0900 Message-ID: <873b03y85h.fsf@uwakimon.sk.tsukuba.ac.jp> References: <200707031442.28402.pogonyshev@gmx.net> <468A3997.2040500@f2s.com> <200707031514.17225.pogonyshev@gmx.net> <87tzskyeuf.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1183596705 10865 80.91.229.12 (5 Jul 2007 00:51:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 5 Jul 2007 00:51:45 +0000 (UTC) Cc: emacs-devel@gnu.org, pogonyshev@gmx.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 05 02:51:42 2007 connect(): Connection refused 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 1I6FZN-0007mO-Ld for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2007 02:51:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6FZM-0005IW-Ul for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2007 20:51:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I6FZI-0005D9-FO for emacs-devel@gnu.org; Wed, 04 Jul 2007 20:51:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I6FZG-00059u-HT for emacs-devel@gnu.org; Wed, 04 Jul 2007 20:51:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6FZG-00059W-CD for emacs-devel@gnu.org; Wed, 04 Jul 2007 20:51:34 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I6FZB-0005dC-VS; Wed, 04 Jul 2007 20:51:30 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 6DB0D1535AF; Thu, 5 Jul 2007 09:51:28 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id EB4201A2968; Thu, 5 Jul 2007 10:02:50 +0900 (JST) In-Reply-To: X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" (+CVS-20070621) XEmacs Lucid X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:74311 Archived-At: Eli Zaretskii writes: > > Don't you still completely lack any policy about how things will be > > handled in the future except "Richard will decide, after hearing the > > advice of other developers"? > I don't see how a piece of software, any software, can resolve > personal problems of this kind. It's not a "personal problem", it's Richard's style, reflecting his constraints as a manager with many responsibilities besides Emacs. If it works for him as maintainer, and Richard as maintainer works for the developers, where's any "problem"? But there is an *opportunity* to improve here. How could a better SCM help to improve the process? The point is that with a SCM which has no concept of "trunk" and which is very helpful to merges among branches, the maintainer's decision timing becomes irrelevant to communication of on-going development among the regular developers. The limiting factor becomes an individual's resources to manage her own workspaces rather than the maintainer's decision to open or close a primary channel of communication. It also enables workers who are only weakly connected to the Internet to keep reasonably up-to-date with *all* branches, and have *full* access to history and other metadata even though the official repository is inconvenient or inaccessible. These primary channels, ie the nominal trunk and the release process, will remain the primary channels to the outside world, and remain under control of the maintainer. However, by using an appropriate SCM, it is possible to separate the issue of day-to-day communication among developers from the issue of what to release when.