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: Sun, 29 Nov 2009 06:52:20 +0100 Message-ID: <87k4x9ane3.fsf@telefonica.net> References: <87skbzblp5.fsf@telefonica.net> <87r5ri9c8c.fsf@telefonica.net> <873a3xzyqw.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: quoted-printable X-Trace: ger.gmane.org 1259474156 6669 80.91.229.12 (29 Nov 2009 05:55:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Nov 2009 05:55:56 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 29 06:55:49 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 1NEclA-0007xl-Mr for ged-emacs-devel@m.gmane.org; Sun, 29 Nov 2009 06:55:49 +0100 Original-Received: from localhost ([127.0.0.1]:38179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NEcl5-0005uN-HH for ged-emacs-devel@m.gmane.org; Sun, 29 Nov 2009 00:55:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NEckx-0005tz-G2 for emacs-devel@gnu.org; Sun, 29 Nov 2009 00:55:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NEcks-0005tG-DF for emacs-devel@gnu.org; Sun, 29 Nov 2009 00:55:34 -0500 Original-Received: from [199.232.76.173] (port=38899 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NEcks-0005tC-4b for emacs-devel@gnu.org; Sun, 29 Nov 2009 00:55:30 -0500 Original-Received: from impaqm3.telefonica.net ([213.4.138.3]:36992) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NEckr-0003uB-ID for emacs-devel@gnu.org; Sun, 29 Nov 2009 00:55:30 -0500 Original-Received: from IMPmailhost4.adm.correo ([10.20.102.125]) by IMPaqm3.telefonica.net with bizsmtp id Atm41d00w2iL0W23PtvU5L; Sun, 29 Nov 2009 06:55:28 +0100 Original-Received: from qcore ([83.43.53.0]) by IMPmailhost4.adm.correo with BIZ IMP id AtvR1d00700G7uz1ktvScP; Sun, 29 Nov 2009 06:55:26 +0100 X-TE-authinfo: authemail="981711563$telefonica.net" |auth_email="981711563@telefonica.net" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" In-Reply-To: <873a3xzyqw.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Sun, 29 Nov 2009 14:27:51 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:117921 Archived-At: "Stephen J. Turnbull" writes: > > will force me to explain what a Bazaar branch is and why it can be bou= nd > > or unbound, and thus would introduce us into the field of multiple > > workflows, which is precisely what the document tries to avoid. > > I agree. One caution I have is that in this case you probably should > also avoid mentioning offline work, which requires understanding what > "bound" means and either how to unbind or how to use the --local flag, > and the implications of that for future work when reconnected. The document has two parts: the first gives you everything you need for commiting changes to Emacs' upstream and the second part hints at possibilities ("see what you are missing") for motivating people to learn more (and ends with a reference to your page). The second part is intentionally vague and having half-cooked concepts there is perfectly okay. For the implications of committing offline, I was thinking on the good-behaved CVS committer, as in the first part of the document. So going offline does not mean here changing his commit criteria, but simply deferring the sending of changes upstream. Do you think that this is still problematic? (due to the pre-push merge, for instance) If yes, I'll remove all explicit indications and leave just a note about the possibility of committing offline. Thanks for your comments. --=20 =C3=93scar