From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs is on Bazaar now. Date: Tue, 29 Dec 2009 03:38:34 +0100 Message-ID: <87skaupkr9.fsf@telefonica.net> References: <87d4206n80.fsf@canonical.com> <87637qhjqu.fsf@red-bean.com> <87fx6urat1.fsf@telefonica.net> <871viepn48.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1262054367 23232 80.91.229.12 (29 Dec 2009 02:39:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2009 02:39:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 29 03:39:20 2009 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 1NPRzU-0004e9-IC for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2009 03:39:20 +0100 Original-Received: from localhost ([127.0.0.1]:44136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPRzU-0003C1-UK for ged-emacs-devel@m.gmane.org; Mon, 28 Dec 2009 21:39:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NPRzQ-0003Bv-HY for emacs-devel@gnu.org; Mon, 28 Dec 2009 21:39:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NPRzM-0003BI-6R for emacs-devel@gnu.org; Mon, 28 Dec 2009 21:39:16 -0500 Original-Received: from [199.232.76.173] (port=33405 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPRzL-0003BD-Tl for emacs-devel@gnu.org; Mon, 28 Dec 2009 21:39:11 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:59121) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NPRzL-000673-9F for emacs-devel@gnu.org; Mon, 28 Dec 2009 21:39:11 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NPRz9-0004Wm-Qx for emacs-devel@gnu.org; Tue, 29 Dec 2009 03:38:59 +0100 Original-Received: from 174.red-83-45-255.dynamicip.rima-tde.net ([83.45.255.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Dec 2009 03:38:59 +0100 Original-Received: from ofv by 174.red-83-45-255.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Dec 2009 03:38:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 58 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 174.red-83-45-255.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux) Cancel-Lock: sha1:CuKexhGyktoEwGi/htKG1hTsAAQ= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:118908 Archived-At: "Stephen J. Turnbull" writes: > Óscar Fuentes writes: > > > Given the slow commit rate on the Emacs project, I see no problem using > > the quickfixes branch on a CVS-like way: bind it to upstream > > This encourages antisocial practices like per-file commits, and > committing ChangeLog separate from the changes. It doesn't encourage certain antisocial practices, just makes them possible. This is easily solvable by monitoring the commits ml and sending polite mails to those committers that do not follow good practices, listing them. I volunteer to do that. The Emacs VC history already contains thousands of revisions consisting on separate commits for the same change. A few more is no problem. > Cf. the OP's > description of his workflow. It gets in the way of use of Bazaar > features like "bzr log -n#" for other developers. Uh? What's the benefit of log -n# for one-revision merges? > That is a problem, if Emacs chooses to see it that way. > > If Emacs has no intention of improving its common workflow, then it's > not a problem. But if that's going to happen, there should be > discussion of whether folks like the OP (who is in good company with > the likes of rms and eliz) should be asked to invest the effort in a > forward-compatible workflow now, or if Emacs should wait to make such > improvements until the old-style workers are good and ready to accept > such changes (presumably due to retirement, since it will be > just as hard later as it is now, so they'll resist it then, too). Well, there is no reason to settle on one Golden Workflow. It is clear that we want to introduce new good practices on how the VC history is developed (one changeset per purpose, etc) but that practices are not incompatible with multiple workflows. The feature branches workflow is great for substantial changes, but a PITA for one-liners. The centralized workflow is perfectly okay (unless you abuse it, or course, but you can abuse the distributed one: what stops you from mixing unrelated changes on the same merge?) Since long time ago I think that the main problem most people here have with the transition to bazaar is that they lack an insight on what a DVCS is (and some even have no previous experience with changeset-based VCSs!) People can understand the centralized usage of bzr without too much effort, but pushing some hackers here to blindly use the distributed workflow is asking for problems. A gradual introduction with a simpler workflow helps in several ways. That's a personal decission, no other is affected by it. Please lets not forget that this is not about making Emacs a model of orthodoxy in DVCS usage. It's about giving hackers a tool that helps them to contribute to Emacs. -- Óscar