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: The fixes-bug field Date: Fri, 17 Jan 2014 09:32:43 +0200 Message-ID: <83sisn12sk.fsf@gnu.org> References: <20140116141315.CA3BE380835@snark.thyrsus.com> <20140116163011.GC17303@thyrsus.com> <83d2jr3ly9.fsf@gnu.org> <20140116180809.GB17770@thyrsus.com> <8338kn3ha8.fsf@gnu.org> <20140116200456.GK17770@thyrsus.com> <83zjmv1upy.fsf@gnu.org> <20140116214714.GA19493@thyrsus.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1389944010 4022 80.91.229.3 (17 Jan 2014 07:33:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jan 2014 07:33:30 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 17 08:33:33 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 1W43vl-0003Zo-PV for ged-emacs-devel@m.gmane.org; Fri, 17 Jan 2014 08:33:29 +0100 Original-Received: from localhost ([::1]:36570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W43vk-0005Da-T2 for ged-emacs-devel@m.gmane.org; Fri, 17 Jan 2014 02:33:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W43vd-0005DV-Cp for emacs-devel@gnu.org; Fri, 17 Jan 2014 02:33:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W43vY-00082a-GI for emacs-devel@gnu.org; Fri, 17 Jan 2014 02:33:21 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:52152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W43vY-00082P-8m for emacs-devel@gnu.org; Fri, 17 Jan 2014 02:33:16 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MZJ00300BDFXY00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 17 Jan 2014 09:32:42 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZJ003RFBMIYG10@a-mtaout20.012.net.il>; Fri, 17 Jan 2014 09:32:42 +0200 (IST) In-reply-to: <20140116214714.GA19493@thyrsus.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:168592 Archived-At: > Date: Thu, 16 Jan 2014 16:47:14 -0500 > From: "Eric S. Raymond" > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > Eli Zaretskii : > > I think we need to figure out these details and more or less agree on > > them, before converting the repository (if needed). The worst thing > > that can happen is to invest all that effort, only to find out later > > that adding more "fixes bug NNN" commits don't work well, or that > > there's a much more easy/elegant way of doing that. > > You guys figure out what policy you want. I'll either implement it > or (less likely) explain why I can't. I don't know enough about git to make useful suggestions, sorry. I also don't quite understand what you mean by "policy". With my understanding of "policy", I thought that part was already clear: we want a committer to be able to say "this changeset is related to bug #XYZZY", and have that info recorded in the history in a way that would later support queries of the type "which commit(s) are related to bug #12345?" (Note that I say "related to" because "fixes" might be inaccurate: we sometimes commit changes that fix only parts of a bug, or even make the bug easier to catch. We also sometimes revert incorrect bugfixes.) If this information will be in the commit message (one suggestion so far, AFAIU), we should define its precise format and location within the commit message. We should also try to find a convenient way of specifying the bug number from the 'git commit' command line. If git supports some extensibility features, we should either find or write an extension for that. If no such features are available at this time, we could ask git developers to provide one for this purpose, like we asked the bzr developers to develop the changelog_merge plugin that avoids merge conflicts in ChangeLog files. Similar issues arise with other possible implementations, like git notes or maybe tags. The above is my take on the "policy" part; comments are welcome. But what I hoped to see and didn't is discussion of git features that could be used for this functionality and comparison of their relative merits and demerits. I don't see how we can make a decision on that without some research in this area, and I hoped that git experts around here will provide their knowledge and expertise to help us make that decision. Instead, I see a lot of discussions about the technique of converting the bugfix information, which is IMO premature, as long as we didn't decide how to store it in git and how to specify it at commit time.