From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bastien Newsgroups: gmane.emacs.devel Subject: Re: Emacs Bazaar repository Date: Wed, 19 Mar 2008 05:44:03 +0000 Message-ID: <87wsnzi7z0.fsf@bzg.ath.cx> References: <87skyvse7k.fsf@xmission.com> <47DA3601.3040507@arbash-meinel.com> <87r6ecsww7.fsf@uwakimon.sk.tsukuba.ac.jp> <200803180148.m2I1m0dB003724@sallyv1.ics.uci.edu> <87fxuoznk2.fsf@red-bean.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205905467 23228 80.91.229.12 (19 Mar 2008 05:44:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2008 05:44:27 +0000 (UTC) Cc: esr@thyrsus.com, Andreas Schwab , Chong Yidong , Emacs Devel , Karl Fogel , Stefan Monnier , "Stephen J. Turnbull" To: dhruva Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 19 06:44:55 2008 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 1Jbr6c-0001WP-Gh for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2008 06:44:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jbr62-0006hJ-7t for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2008 01:44:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jbr5x-0006h7-0s for emacs-devel@gnu.org; Wed, 19 Mar 2008 01:44:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jbr5v-0006gv-IO for emacs-devel@gnu.org; Wed, 19 Mar 2008 01:44:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jbr5v-0006gs-Cf for emacs-devel@gnu.org; Wed, 19 Mar 2008 01:44:11 -0400 Original-Received: from fg-out-1718.google.com ([72.14.220.154]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jbr5u-0000HF-TO for emacs-devel@gnu.org; Wed, 19 Mar 2008 01:44:11 -0400 Original-Received: by fg-out-1718.google.com with SMTP id d23so299064fga.30 for ; Tue, 18 Mar 2008 22:44:09 -0700 (PDT) Original-Received: by 10.82.182.1 with SMTP id e1mr5019419buf.21.1205905448642; Tue, 18 Mar 2008 22:44:08 -0700 (PDT) Original-Received: from bzg.ath.cx ( [81.99.213.34]) by mx.google.com with ESMTPS id c24sm3510667ika.10.2008.03.18.22.44.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 22:44:07 -0700 (PDT) Original-Received: by bzg.ath.cx (Postfix, from userid 1000) id 60FB7157978; Wed, 19 Mar 2008 05:44:02 +0000 (GMT) In-Reply-To: (dhruva's message of "Tue, 18 Mar 2008 15:30:00 +0530") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:92961 Archived-At: dhruva writes: > I just hope it the decision is based on technical facts rather than > affiliations and emotions... I think the right dimension to consider is the social one. The assumption in the discussion so far has been namely this one: it is possible to use a dVCS instead of the current CVS without switching to a new project workflow. Even better: most dVCS are so flexible that you can adapt your project workflow _after_ you start using one of them. This has been specifically stated in Stephen J. Turnbull's post (from January 08): http://article.gmane.org/gmane.emacs.devel/86530 > Thus I suggest that the project workflow discussion be postponed until > the core stakeholders are satisfied that the new tools are functioning > stably in the current workflow. This will take only a month, at most > two, once the tools are chosen. As you point out, a big advantage of > a dVCS is the flexibility of the workflow even after it is installed. > There is no big loss to waiting a bit, and a potential large gain: the > improved understanding of the tools that the core stakeholders will > have. ... and this is clearly *true* when the use of the dVCS system is not problematic /per se/. Now we are in a situation where the decision for the dVCS has been made (bzr) and yet this decision is not satisfactory for many of us. So instead of trying to convince 120 developpers to use bzr in its current unsatisfactory state, maybe it's time to open the discussion about the project workflow, and see if the number of people to convince cannot be reduced by such a discussion. Now referring to Gregory Collins' post[1] about the different workflows, I think the current workflow for Emacs would be translated into a mix of the "star" topology (where many developers are entitled to write in any part of the codebase) and the "Lieutenant" topology (where the majority of developers are responsible for subsystems.) This would mean that some core developers have access to all the code, and need to agree about when bzr is good enough, and other developers are free to use whatever they want, provided that they send patches in the form that the core developers prefer. I guess at most 25% of the current 120 developers would need to have access to all the code. The rest would be responsible for a limited part -- either a large directory like Gnus or a single Elisp file. Of course, it would be easier if all the Lieutenants were using bzr, because the core team would just need to pull from the lieutenants repositories. But the only true requisit is that lieutenants keep pulling from the Emacs codebase and make sure the code they are responsible for works correctly with the latest Emacs code. We spent time learning that the radical change with dVCS is that they move the constraints for the workflow from the technical to the social dimension. It's strange that the discussion about bzr is just a technical one, without consideration about the social change this already calls for. Notes: [1] http://article.gmane.org/gmane.emacs.devel/86503 -- Bastien