From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Torvald Riegel Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: Update copyright dates not handled by scripts/update-copyrights [committed] Date: Mon, 02 Jan 2017 18:55:38 +0100 Message-ID: <1483379738.13143.115.camel@redhat.com> 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="UTF-8" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1483379767 1247 195.159.176.226 (2 Jan 2017 17:56:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2017 17:56:07 +0000 (UTC) Cc: Mike Frysinger , Florian Weimer , libc-alpha@sourceware.org To: Joseph Myers Original-X-From: libc-alpha-return-76537-glibc-alpha=m.gmane.org@sourceware.org Mon Jan 02 18:56:04 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:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding; q=dns; s=default; b=HCkCtjn3m+fyEhnFW0FVhrt+3nJ5FShAKk5jU724Fj3 J8Y3eHxB5eoqip9bj7PfrSorQVmv2nxWcyl5vt7hTTZ6W99rpVgT46b1oEOVBERS iNH/FMDvcXAGzRPS2SHPJY//DTaACjxIvBbNpeFOzI1Il4scs3KwDuaMFnFL6wAQ = 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:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding; s=default; bh=0iC+6lMDCo1wchyhos5IUE19AVA=; b=pZZTzkKWMQi/3Acbr bBct8VDmxKNTPK3w6Y8hMct4Hr8LVdVXYppUTOhSKBzOqsmfl2BMH0sdjiTWNQiU j6IPxCID1IVpYr09hosAcsCGwIIjwgpdR8lLvFmkGwNvtd6xiOm3AASe6u7xXpU2 +velVmDH3bGfSdw8Hl2ubzl7kU= 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: mx1.redhat.com In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:68892 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 1cO6pt-0007Ie-In for glibc-alpha@blaine.gmane.org; Mon, 02 Jan 2017 18:55:53 +0100 Received: (qmail 76670 invoked by alias); 2 Jan 2017 17:55:52 -0000 Received: (qmail 76651 invoked by uid 89); 2 Jan 2017 17:55:52 -0000 On Mon, 2017-01-02 at 17:19 +0000, Joseph Myers wrote: > 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 - Thanks. That's a useful ruleset. > 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). So, who should this go to at the FSF side? maintainers@gnu.org? Do you want to start this discussion? Or can I just copy-and-paste what you wrote above? Do we have consensus in glibc that aside from any legal considerations regarding attribution (an important point you made, thanks), we'd like to have a rule like the one you proposed above in place so we don't have to maintain changelogs? Regarding the legal considerations, do we need anything else beyond the FSF's opinion on this?