From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Joseph Myers Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: Update copyright dates not handled by scripts/update-copyrights [committed] Date: Mon, 2 Jan 2017 17:19:58 +0000 Message-ID: References: <0d577e78-86dc-5c4d-7afc-f4ff6e3a5eb9@redhat.com> <20170101095738.GH16617@vapier> <1483369707.13143.80.camel@redhat.com> <1483371772.13143.93.camel@redhat.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Trace: blaine.gmane.org 1483377637 10311 195.159.176.226 (2 Jan 2017 17:20:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2017 17:20:37 +0000 (UTC) User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Cc: Mike Frysinger , Florian Weimer , To: Torvald Riegel Original-X-From: libc-alpha-return-76530-glibc-alpha=m.gmane.org@sourceware.org Mon Jan 02 18:20:33 2017 Return-path: Envelope-to: glibc-alpha@blaine.gmane.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=b+HFM hTUqh4WGO4RJolM6ckivWCGLy9eO3YwqnCNqYcggXnm0tjR75szefzT0YNFQW15z 8E1Gym1QTJdvkr20n2818VoWqi/HRm/AaT00QzyFutk3pHUB1r3rP/Xv1Gft0eDh 0cQs7nLKYkikwaa1HTeHzmehMkoCoMgZSbJzFI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=ZGdS36S6VHa AZLsqjrpEZYhs88A=; b=TNGi3AS7++8KEsByKg4XbJ9evYlFvbablxp0zj/nwBX rLBexriQWgHDULdl5Ns4CVwEEW+fQOT7CIaPJQSNI+R7cReKtW0SIPDQ0zXAWVuM cUJim0RHQqe0HVrJc19eQU72Xq/nMVYM2uGlPwK2x62EnwwiDN0HTNGJhzQQi7NY = Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: relay1.mentorg.com In-Reply-To: <1483371772.13143.93.camel@redhat.com> X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) Xref: news.gmane.org gmane.comp.lib.glibc.alpha:68885 Archived-At: Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cO6Hf-0001oY-5I for glibc-alpha@blaine.gmane.org; Mon, 02 Jan 2017 18:20:31 +0100 Received: (qmail 53432 invoked by alias); 2 Jan 2017 17:20:26 -0000 Received: (qmail 53383 invoked by uid 89); 2 Jan 2017 17:20:26 -0000 On Mon, 2 Jan 2017, Torvald Riegel wrote: > > The newer logs are a matter of the GNU Coding Standards. That is, if you > > don't want to maintain information about "what" changed in that particular > > form, you should be persuading the GCS maintainers to allow just logging > > descriptions of what and why changed at the logical level rather than the > > level of individual files and functions (in the case where a version > > control system provides tracking of the "what" ... not all GNU packages > > have public version control). > > Are you saying that from your point of view, GCS is the only significant > reason for maintaining changelogs? My suggestion is that it would be reasonable to argue to the GCS maintainers that ChangeLog-format logs need not be maintained for a package for which all of the following are true: * it has public version control, * in a distributed VCS, * where commits are made for each logical change, not batched into a commit per release (see bash for an example of such batching) or per day or other such batching, * with authors not just committers tracked, * with commit messages describing the logical "what" changed (but not describing the physical "what" at the level of changes to individual files and functions). That is, when all the above are true, the information about changes is more usefully available through the VCS than through ChangeLog-style messages and people wanting that information will be expecting to go to the VCS for it rather than to find it in the release tarballs, so ChangeLog-style messages can be considered obsoleted by the VCS in that case (and in that case, the GCS requirements for ChangeLog files do not serve a useful technical purpose - this is a separate matter from any legal reasons there might be for including such information about changes and their authorship in release tarballs). > Maybe we should just announce that we'll stop doing changelogs and see > whether anybody complains. If people complain, it would be interesting That's not an appropriate way to work for a GNU package. We need to work with the GNU project (and quite possibly, the FSF in turn work with their lawyers to establish if there are any legal reasons relating to attribution of changes within releases). If the GCS were then changed along the lines I propose above, we'd still need to establish appropriate conventions for commit message contents - that is, that any nontrivial change should include a description in the commit message along the lines of what goes in the mailing list posting of the patch. But we can of course establish such a rule for meaningful commit messages independently of a change to the GCS. -- Joseph S. Myers joseph@codesourcery.com