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: Git transition checklist Date: Wed, 8 Jan 2014 15:11:04 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20140108201104.GC5374@thyrsus.com> References: <20140108135200.8ECF9380834@snark.thyrsus.com> <837gaafij8.fsf@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 1389211880 900 80.91.229.3 (8 Jan 2014 20:11:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jan 2014 20:11:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 08 21:11:27 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 1W0zTF-0005SS-FY for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 21:11:21 +0100 Original-Received: from localhost ([::1]:48755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0zTF-0006T1-0N for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 15:11:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0zT7-0006SD-SQ for emacs-devel@gnu.org; Wed, 08 Jan 2014 15:11:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0zT3-0007d8-J8 for emacs-devel@gnu.org; Wed, 08 Jan 2014 15:11:13 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:60468 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0zSy-0007cM-TY; Wed, 08 Jan 2014 15:11:04 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 593BC380E42; Wed, 8 Jan 2014 15:11:04 -0500 (EST) Content-Disposition: inline In-Reply-To: <837gaafij8.fsf@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:167803 Archived-At: Eli Zaretskii : > If I run the above git command in the Emacs git repo, I get this: > > $ git describe --tags > mh-e-8.5-4522-gaa5ae3b > > I doubt that we want this. We want the git sha1 value of the last > commit instead, I think. Why? If the repo has proper release tags (which it will - I'm going to do that), knowing the offset from the last release conveys more information than a lump of SHA1. > At least here (on MS-Windows), "git describe" is not very fast: with a > warm cache it takes 0.265 sec, with a cold cache it takes several > seconds. > > But a command that prints the sha1 value should be much faster (about > 30 to 45 msec here). Performance may be an overriding factor her, but I'd prefer we think about the use cases for the information and decide what we'd *like* it to do first. > > The change to integrate this and fix its callers is easy, five minutes' > > work which I will cheerfully do immediately after the repo switchover. > > No need to do it before as it really only becomes crucial to have this > > working for the next point release. > > No, I think it needs to be done before the first user checks out the > git repo after the switch, because that signature is important in bug > reports. We don't want to have builds of Emacs that don't identify > the git commit they are based on, because that makes it harder to > decide whether a bug was already fixed. > > So either the above function should be added to Emacs before the > switch, wrapped with some code that would activate it when git starts > to be used, or the repo should be locked for pulls for a few moments > after the switch, until the function is committed. Very well. One of these things can be made to happen; I'll ensure the transition plan spells this out. > > Nobody else explicitly suggested any additional preconditions. > > I think we have identified another one today: repack the savannah > repository, to avoid both slow initial clone and, what's more, local > repacking that is problematic on slow or low-memory machines. Right, and I saw the mail about where to post that request, too. I expect one of the people having performance problems will do that. -- Eric S. Raymond