From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Referring to revisions in the git future. Date: Thu, 30 Oct 2014 07:51:28 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20141030115128.GA7645@thyrsus.com> References: <20141028223312.GB6630@acm.acm> <87fve7b6p7.fsf@fencepost.gnu.org> <20141029095248.GA14601@thyrsus.com> <87y4rz9m4d.fsf@fencepost.gnu.org> <83ppdb0wv8.fsf@gnu.org> <87fve79c57.fsf@fencepost.gnu.org> <83lhnz0vt3.fsf@gnu.org> <20141030083258.GB2683@thyrsus.com> <874mul97mu.fsf@fencepost.gnu.org> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1414785769 31419 80.91.229.3 (31 Oct 2014 20:02:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2014 20:02:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 31 21:02:44 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XkIPD-000125-A4 for ged-emacs-devel@m.gmane.org; Fri, 31 Oct 2014 21:02:43 +0100 Original-Received: from localhost ([::1]:42349 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkIPC-0001hS-M5 for ged-emacs-devel@m.gmane.org; Fri, 31 Oct 2014 16:02:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkETF-0005XE-Ml for emacs-devel@gnu.org; Fri, 31 Oct 2014 11:51:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjoGq-0002qT-J9 for emacs-devel@gnu.org; Thu, 30 Oct 2014 07:52:08 -0400 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:39602 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjoGl-0002er-KN; Thu, 30 Oct 2014 07:51:59 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id AFFDE3834CA; Thu, 30 Oct 2014 07:51:28 -0400 (EDT) Content-Disposition: inline In-Reply-To: <874mul97mu.fsf@fencepost.gnu.org> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176152 Archived-At: David Kastrup : > At any rate, that's not an on-site resource for somebody having > installed a full copy of Emacs. One of the main points of a distributed > version control system is the ability to work offline. > > "There is some instruction somewhere on the Internet" is not a > sufficient excuse for leaving Emacs without any resources pointing out > the desired workflow for Emacs developers. > > If "the wiki" is an authoritive source for the workflow of Emacs > developers, it means that anybody who wants to can tell the Emacs > developers how to do their work. You may be right. But this is not a git transition issue. There is some in-tree workflow documentation in admin/notes/repo. It isn't very good. My transition patch fixes it to refer to git commands rather than bzr ones (and deletes some sections about things like loggerhead that will no longer be relevant). It still isn't very good, but reworking it is out of scope for what I'm trying to get done before conversion day. After that, we can have a *separate* conversation about the proper role of the in-tree notes vs. the wiki, whether access to the wiki should be restricted in some way, etc. I have no particular opinions about those matters. I do have both the ability and the willingness to write good documentation, so I expect I will end up doing a lot of the writing if we decide to reorganize. What I am not willing to do is dive into that matter *right now*. The transition job is huge and it's not done yet. (Pull the repo containing my transition machinery sometime and browse it. You should find the experience ... enlightening.) It's all to the good that the transition is causing people to pay attention to back issues that they normally ignore, but when these come up please try to queue them for later rather than talking as if the solution is a requirement for the transition itself. -- Eric S. Raymond