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 repository ready? Date: Sat, 28 Nov 2009 11:57:54 +0200 Message-ID: <83my27m0nx.fsf@gnu.org> References: <877htl53tc.fsf@telefonica.net> <87ws1ku7zd.fsf@red-bean.com> <87hbso4s13.fsf@telefonica.net> <83aaygoy90.fsf@gnu.org> <87vdh36d48.fsf@telefonica.net> <831vjrptha.fsf@gnu.org> <87einr63b6.fsf@telefonica.net> <83y6lzo9e7.fsf@gnu.org> <871vjr750o.fsf@uwakimon.sk.tsukuba.ac.jp> <83tywnnq34.fsf@gnu.org> <873a475bsr.fsf@telefonica.net> <87ocmu7x9c.fsf@red-bean.com> <87zl6crij4.fsf@red-bean.com> <87hbsifdsr.fsf@telefonica.net> <87d435sn0b.fsf@uwakimon.sk.tsukuba.ac.jp> <87hbsgc4l8.fsf@telefonica.net> <83ocmnnc5d.fsf@gnu.org> <877htbaitb.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1259402426 7972 80.91.229.12 (28 Nov 2009 10:00:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Nov 2009 10:00:26 +0000 (UTC) Cc: ofv@wanadoo.es, 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 Sat Nov 28 11:00:19 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 1NEK6D-0007DT-24 for ged-emacs-devel@m.gmane.org; Sat, 28 Nov 2009 11:00:18 +0100 Original-Received: from localhost ([127.0.0.1]:60630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NEK6C-00088y-H7 for ged-emacs-devel@m.gmane.org; Sat, 28 Nov 2009 05:00:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NEK64-00087o-Kx for emacs-devel@gnu.org; Sat, 28 Nov 2009 05:00:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NEK5z-00085y-CD for emacs-devel@gnu.org; Sat, 28 Nov 2009 05:00:08 -0500 Original-Received: from [199.232.76.173] (port=50173 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NEK5z-00085o-5b for emacs-devel@gnu.org; Sat, 28 Nov 2009 05:00:03 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:41742) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NEK5v-0005Z6-Q9; Sat, 28 Nov 2009 05:00:00 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0KTT00000CTM0W00@a-mtaout21.012.net.il>; Sat, 28 Nov 2009 11:59:58 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.70.37.193]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KTT00KACD3XOM70@a-mtaout21.012.net.il>; Sat, 28 Nov 2009 11:59:58 +0200 (IST) In-reply-to: <877htbaitb.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:117904 Archived-At: > From: "Stephen J. Turnbull" > Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , > rms@gnu.org, > emacs-devel@gnu.org > Date: Sat, 28 Nov 2009 04:06:40 +0900 > > Eli Zaretskii writes: > > > I personally would regret [a document that advocates a particular > > workflow to start from]. I think I'm grown-up enough to not have > > me spoon-fed. Give me the information and let me decide myself > > what's best for me, even if I make some mistakes on the way. > > But BzrForEmacsDevs is not about what's best for you. Figuring *that* > out is your privilege, and your problem. You seem to interpret the ``I personally'' thing too literally. I wrote that in the personal style, but it should have been clear that I thought others will feel that way as well: that patronizing us is not the way to go. Evidently, it wasn't clear enough, sorry. > BzrForEmacsDevs is about designing a recommended starter workflow > that the majority of Emacs hackers can adopt without worrying too > much, while avoiding the common mistakes that make life a lot less > pleasant for the other people accessing the repository. It remains to be proven whether a workflow exists that would be good for ``the majority of Emacs hackers''. The wiki page already talks about several kinds of hackers, and suggest different workflows for each one of them. More importantly, what little I've read about dVCS practices suggests that the best workflow depends heavily on a combination of factors, such as the number and typical activity levels of core developers, the amount of overlap in the areas where they and their downstream hackers develop, the explicit division of maintainership between the core developers, etc. I think all these factors change from project to project, so when a large project such as Emacs switches to a dVCS, it will take time for us to figure out all these factors and find the right set of workflows. So I wouldn't worry too much if several workflows were described on the wiki, and not a single one, since trying to have a single one might simply yield a wrong one. If we worry about a starter workflow, then that can be gleaned from the Bazaar's getting started tutorial. It's pretty clear, and therefore it's easy to get started. The question that bothers me is what's next. We didn't decide to switch to Bazaar just to do the same as we did with CVS. Therefore, the issue of the workflows for the Emacs project as a whole and for the individual developers _should_be_ an important one, not something swept under the rug because it's deemed ``confusing''. Nothing is confusing if it's clearly explained, especially with the audience we have here: experienced code developers who know one or two things about data structures and algorithms, so describing some of the inner workings of Bazaar that underlie some of the recommendations for and against workflows should not be hard. Yes, it would make the wiki page substantially longer, but we could organize it in a way that people who are impatient to get to the bottom line will have it. > See http://lkml.indiana.edu/hypermail/linux/kernel/0805.2/0539.html > for some of Linus's wisdom on the social aspects of workflows. That > really rings true for me, but do you have any idea what he's talking > about? I think I do, although I don't necessarily see how that's related to the present discussion. Perhaps you assume that I want the best workflow for me at the expense of others. If so, that's false, and if what I wrote could somehow be interpreted to that effect, I'm sorry. What I really meant was that describing several possible workflows with their pros and cons would enable a discussion among developers that would yield the set of recommended workflows (I don't believe there's only one) that would serve well both the individual developers and their peers, and the project as a whole. > > What is ``full dVCS practice''? Can you describe it (or was it > > already described in this thread)? > > Heh. Ask any three developers, you'll get four opinions. :-) What's yours, if I may ask?