unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Torvald Riegel <triegel@redhat.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Mike Frysinger <vapier@gentoo.org>,
	Florian Weimer <fweimer@redhat.com>,
	libc-alpha@sourceware.org
Subject: Re: Update copyright dates not handled by scripts/update-copyrights [committed]
Date: Mon, 02 Jan 2017 16:42:52 +0100	[thread overview]
Message-ID: <1483371772.13143.93.camel@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1701021515550.19233@digraph.polyomino.org.uk>

On Mon, 2017-01-02 at 15:23 +0000, Joseph Myers wrote:
> On Mon, 2 Jan 2017, Torvald Riegel wrote:
> 
> > On Sun, 2017-01-01 at 04:57 -0500, Mike Frysinger wrote:
> > > even better: let's delete them and be done.
> > 
> > Yes, please.
> 
> The old logs are routinely useful for identifying the logical changesets 
> for changes before the move to git.

That's true.  My hate for them was a little strong it seems ;)  The old
logs should not be removed.

> 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?

In my opinion, the coding standards need to serve the projects.  If we
can find consensus in glibc that it does not give us a net win, then it
doesn't serve us.  One could still argue that it may serve
users/developers that are not interacting with the glibc community
directly (in which case they'd be told to just use git, please...);
However, beyond grouping changes (ie, "logical change sets" as you write
above), the changelogs aren't really useful IMO: they details vary a lot
regarding "what", and "why is mostly not covered at all.  Thus,
developers outside of the glibc developer community would still have to
consult libc-alpha or the git logs, so I see no significant benefit of
the changelogs.

> Absent such a GCS change, we can still move 
> to automatic generation but that requires various infrastructure work such 
> as I outlined.

Yes, and just to be clear, I think something like what you outline would
be a benefit over the existing situation.  However, I'd much prefer for
you (or/and everyone else) to not have to spend the effort on that
infrastructure work and just get rid of changelogs.

Maybe we should just announce that we'll stop doing changelogs and see
whether anybody complains.  If people complain, it would be interesting
to see whether they can show that what they perceive as a loss when not
having changelogs is larger than the win for the glibc developers (and
thus all of glibc's users, indirectly).





  reply	other threads:[~2017-01-02 15:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-01  0:27 Update copyright dates not handled by scripts/update-copyrights [committed] Joseph Myers
2017-01-01  7:22 ` Florian Weimer
2017-01-01  9:57   ` Mike Frysinger
2017-01-02 15:08     ` Torvald Riegel
2017-01-02 15:23       ` Joseph Myers
2017-01-02 15:42         ` Torvald Riegel [this message]
2017-01-02 17:19           ` Joseph Myers
2017-01-02 17:27             ` Joseph Myers
2017-01-02 18:03               ` Torvald Riegel
2017-01-02 17:55             ` Torvald Riegel
2017-01-02 18:01               ` Joseph Myers
2017-01-02 18:03             ` Torvald Riegel
2017-01-02 13:45   ` Joseph Myers
2017-01-02 13:55     ` Florian Weimer
2017-01-02 14:00       ` Joseph Myers
2017-01-02 15:50     ` Paul Eggert
2017-01-02 17:22       ` Joseph Myers
  -- strict thread matches above, loose matches on Subject: below --
2020-01-01  0:22 Joseph Myers
2019-01-01  0:16 Joseph Myers
2018-01-01  0:41 Joseph Myers
2016-01-04 16:27 Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1483371772.13143.93.camel@redhat.com \
    --to=triegel@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).