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: Basic Bazaar guide for Emacs hackers. Date: Mon, 30 Nov 2009 04:26:53 +0100 Message-ID: <87y6lo8zgi.fsf@telefonica.net> References: <87skbzblp5.fsf@telefonica.net> <87y6log42q.fsf@red-bean.com> 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 1259551861 26561 80.91.229.12 (30 Nov 2009 03:31:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Nov 2009 03:31:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 30 04:30:54 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 1NEwyR-0003Hl-7C for ged-emacs-devel@m.gmane.org; Mon, 30 Nov 2009 04:30:52 +0100 Original-Received: from localhost ([127.0.0.1]:39381 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NEwyQ-00027t-Pe for ged-emacs-devel@m.gmane.org; Sun, 29 Nov 2009 22:30:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NEwyL-000268-1c for emacs-devel@gnu.org; Sun, 29 Nov 2009 22:30:45 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NEwyF-00022E-5U for emacs-devel@gnu.org; Sun, 29 Nov 2009 22:30:43 -0500 Original-Received: from [199.232.76.173] (port=53094 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NEwyF-00022B-20 for emacs-devel@gnu.org; Sun, 29 Nov 2009 22:30:39 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:54782) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NEwyE-0000YP-Ib for emacs-devel@gnu.org; Sun, 29 Nov 2009 22:30:38 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NEwyA-0003BW-2j for emacs-devel@gnu.org; Mon, 30 Nov 2009 04:30:34 +0100 Original-Received: from 99.red-83-35-102.dynamicip.rima-tde.net ([83.35.102.99]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Nov 2009 04:30:34 +0100 Original-Received: from ofv by 99.red-83-35-102.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Nov 2009 04:30:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 111 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 99.red-83-35-102.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:T7e8jLGFt842z5sSRb2xeSvuVf8= 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:117947 Archived-At: Karl Fogel writes: > Óscar Fuentes writes: >> [Posted this to help-emacs by accident.] >> >> http://www.emacswiki.org/cgi-bin/emacs/BzrQuickStartForEmacsDevs >> >> I know some of you are pushing hard for introducing complete and correct >> dVCS practices among the Emacs developers. That is laudable but IMHO >> unrealistic to expect since day one. So it is intended as a minimum >> knowledge guide for not being left out. It is an appetizer too. >> >> If you think that it is the wrong way to (not) enter dVCS, I'll delete >> it or put a big warning sign at the beginning. > > The more options we offer, the more confused people will be. ... unless each person finds the option adequate for him among the available ones. What is confusing, IMHO, is to provide several options with similar degree of complexity, and that demand from the user to apply new concepts and see himself on not-yet-experienced scenarios for deciding which one is the right one for him. > Also, the more different workflows developers use, the more difficult > it will be for us to support each other. Forcing developers to use workflows that they do not understand creates support requests. Forcing developers to use workflows that they find gratuitously complicated scares them away. > Can we please not fall into this tar pit? :-) > > I hate to say this, knowing how hard you must have worked on it, but I'm > worried the document will do more harm than good in the long run. IMHO, > either delete it or maybe just put some kind of warning sign at the > beginning, linking to [1]. What's exactly the reason for the warning? Is it like they will damage the Emacs project if they choose that workflow? I don't think so. Maybe they damage themselves by not using a more effective workflow for their specific needs, but that is implicit all along the document and, really, it is up to them to pick wathever they find appropriate. And, actually, that workflow is perfectly fine for occassional contributors or people who work on simple tasks like quick-fixes. The document is a sort of "this is the minimum you need to know, but keep reading if you want more." Either the developer thinks that the workflow is adequate and he keeps contributing or he wants more and goes to your document. What's wrong with that? > Coming from the Subversion-and-CVS world, I needed less than a day to > get used to the Bazaar/distributed way of working. It just isn't that > hard. Funny. I come from CVS and Subversion too, but learning dVCS took me several days of highly motivated effort to re-program my mind. Maybe the difference among you and me is that I was not a Subversion developer and version control concepts were not in my mind all day long. I'm pretty sure that when you started your bzr usage all its underlying concepts were already familiar to you. > Anyone who works on Emacs can get used to it in about that amount of > time. Sure, there will be little questions here and there, but the > main loop documented at [1] will be comprehensible to all. > > No one here is saying we should introduce "complete and correct dVCS > practices...since day one". I *am* saying that it is completely > reasonable to expect Emacs developers to read and understand [1], and to > work that way from that point forward, until they understand Bazaar well > enough to vary their workflow as they wish. You are overestimating the Emacs developers. Not their intelligence or knowledge about CS. You are overestimating their commitment to the project. AFAIK most Emacs committers can't be considered "regular" contributors. All of them are volunteers. They appear, do some bug fixing, add features or even create a new framework, but then they vanish for months or years. Expecting from them to learn a fringe tool like Bazaar on certain "recommended" way and then not having to re-learn it when they come back after three months is unrealistic. Expecting from somebody, who simply wants to correct the bug that annoys him so much, to learn a new tool together with a series of new concepts and practices for creating a simple patch, is raising the entry barrier quite a bit. > There's nothing wrong with the content of BzrQuickStartForEmacsDevs. > It's just that if Emacs developers start doing things that way too, then > the total support burden on the community goes up. We should not > stimulate that situation if we can avoid it. The intent of the document is to *lower* the support burden. If a CVS committer (or anyone with CVS or Subversion experience) has problems putting into practice what's described there, then your guide will be absolutely incomprehensible for him. I have no problem at all deleting the document if it damages the transition to Bazaar. But so far, your reasons for doing it are not convincing at all to me and just demonstrates a misunderstanding of the demography of Emacs and their current VC practices. All this said with respect and appreciation. -- Óscar