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 14:04:28 +0000 Message-ID: <87y78e4xoz.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> <87wsnzi7z0.fsf@bzg.ath.cx> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205935534 18513 80.91.229.12 (19 Mar 2008 14:05:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2008 14:05:34 +0000 (UTC) Cc: Emacs Devel To: "Juanma Barranquero" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 19 15:06:03 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 1Jbyur-0004Bx-Mu for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2008 15:05:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JbyuH-0004cS-JU for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2008 10:04:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JbyuC-0004af-DA for emacs-devel@gnu.org; Wed, 19 Mar 2008 10:04:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JbyuA-0004ZW-NH for emacs-devel@gnu.org; Wed, 19 Mar 2008 10:04:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JbyuA-0004ZR-L7 for emacs-devel@gnu.org; Wed, 19 Mar 2008 10:04:34 -0400 Original-Received: from ug-out-1314.google.com ([66.249.92.175]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jbyu9-0004S8-Ov for emacs-devel@gnu.org; Wed, 19 Mar 2008 10:04:34 -0400 Original-Received: by ug-out-1314.google.com with SMTP id a2so1464250ugf.48 for ; Wed, 19 Mar 2008 07:04:32 -0700 (PDT) Original-Received: by 10.78.162.4 with SMTP id k4mr864234hue.43.1205935471593; Wed, 19 Mar 2008 07:04:31 -0700 (PDT) Original-Received: from bzg.ath.cx ( [78.113.180.99]) by mx.google.com with ESMTPS id y37sm326578mug.19.2008.03.19.07.04.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Mar 2008 07:04:30 -0700 (PDT) Original-Received: by bzg.ath.cx (Postfix, from userid 1000) id 4DCC3157978; Wed, 19 Mar 2008 14:04:27 +0000 (GMT) In-Reply-To: (Juanma Barranquero's message of "Wed, 19 Mar 2008 10:42:44 +0100") 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:92977 Archived-At: "Juanma Barranquero" writes: >> 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 is one assumption. The other one is that all dVCS (or at least, > the three or four "major" ones) are largely equivalent. Both seem to > be false at this moment. They are not equivalent in terms of performance, but I think the assumption was more precisely that all dVCS are equivalent in terms of their ability to adapt to any workflow. This assumption is true IMO. > Until now the Emacs model has been that everyone with write access is > trusted to display some common sense, and it has worked quite well. Sure, thanks to people on this mailing list! > Limiting who can write to the canonical repository and establishing > that kind of hierarchy seems like fixing a non-existent problem. I didn't want to fix problems in the current workflow. One of the benefits of using a dVCS is that you can envision different workflows. If everybody were okay with bzr then there would be no point in trying to imagine other workflows before using the new dVCS. But since bzr has some annoying shortcomings, maybe it is useful to be sure that everyone wants to stick to the current workflow before avoiding bzr because of its inability to preserve this workflow... One of the shortcomings of the current workflow is this one: some piece of code in Emacs is actively developped outside of the Emacs CVS (Gnus, ERC, Org, etc.) Since these pieces are also part of Emacs, any change on them in the Emacs CVS requires someone to report the changes in the local, independant repository of the module. This is double work, and such energy could be spared with the "Lieutenant" topology previously described. > As you say, it is a social issue. If I do a pervasive change in ido or > cua, I *will* send it to Kim, for example; but I don't want to have to > pass through someone to fix a typo or correct a silly oversight. I don't propose to sparse the code into areas where only one developer can make changes. I propose to think about what a _distributed_ VCS would be really useful for as a collective tool, in hope that such a discussion might give directions in the evaluation of bzr. (Of course, a dVCS is already useful from an individual point of view: being able to commit locally, to work on several local branches, all this means it's already worth using a dVCS. But bzr might also be useful as a collective tool.) > Let's not create bureaucracy until we know we need it. Well, I believe the real benefit of a dVCS is precisely to avoid bureaucracy -- provided that you can adapt the tool to the way people want to work together with it, and this requires some discussion. -- Bastien