From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bzr workflow Date: Wed, 13 Jan 2010 06:20:45 +0200 Message-ID: <83wrzm7i02.fsf@gnu.org> References: <4B4B93AB.3030903@gnu.org> <87skac1fy7.fsf@telefonica.net> <4B4C28F6.9000209@swipnet.se> <87ockz1ztm.fsf@telefonica.net> <4B4C4360.2040707@swipnet.se> <87fx6a3fyn.fsf@uwakimon.sk.tsukuba.ac.jp> <87r5puspr5.fsf@red-bean.com> <877hrm3b4y.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1263356447 21121 80.91.229.12 (13 Jan 2010 04:20:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jan 2010 04:20:47 +0000 (UTC) Cc: kfogel@red-bean.com, ofv@wanadoo.es, jan.h.d@swipnet.se, emacs-devel@gnu.org, lekktu@gmail.com To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 13 05:20:39 2010 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 1NUuij-0004eg-Ex for ged-emacs-devel@m.gmane.org; Wed, 13 Jan 2010 05:20:37 +0100 Original-Received: from localhost ([127.0.0.1]:54171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUuij-0003oh-Ty for ged-emacs-devel@m.gmane.org; Tue, 12 Jan 2010 23:20:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUuiT-0003hW-IH for emacs-devel@gnu.org; Tue, 12 Jan 2010 23:20:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUuiP-0003fE-Kr for emacs-devel@gnu.org; Tue, 12 Jan 2010 23:20:21 -0500 Original-Received: from [199.232.76.173] (port=42510 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUuiP-0003eu-Aa for emacs-devel@gnu.org; Tue, 12 Jan 2010 23:20:17 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:39717) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUuiO-0005S2-7l for emacs-devel@gnu.org; Tue, 12 Jan 2010 23:20:16 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KW6004003P4Y300@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Wed, 13 Jan 2010 06:20:07 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.60.183]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KW6004SE41IXR10@a-mtaout22.012.net.il>; Wed, 13 Jan 2010 06:20:07 +0200 (IST) In-reply-to: <877hrm3b4y.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) 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:119896 Archived-At: > From: "Stephen J. Turnbull" > Date: Wed, 13 Jan 2010 13:02:37 +0900 > > No. I just really dislike that workflow, personally. (I accumulate > typo fixes and the like separately -- what's the rush? -- and don't > trust even the simplest code change to be correct without testing, at > least a compile, link, re-byte-compile, run test suite -- so my > quickfixes are batched, too.) But that's a personal bias that I was > aware of, and I hope I mostly accounted for. Testing before committing is (or should be) good practice, not just personal bias. I always at least rebuild Emacs, even if it's just a typo in a comment, before committing. I was doing that with CVS as well. There's nothing more embarrassing than botching the build by committing untested changes. > But in Bazaar with trunk bound to the public repo, that won't happen. > I didn't realize how powerful that technique would be. I still don't > like it myself, but now I have convinced myself that it won't cause > any issues for other developers. So I do not oppose including it > in BzrForEmacsDevs. Yes, I think we should do that. I'm doing all my quick-fixing stuff in the trunk directly.