[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Script to generate ChangeLogs automatically
From: |
Joseph Myers |
Subject: |
Re: Script to generate ChangeLogs automatically |
Date: |
Mon, 3 Dec 2018 18:42:50 +0000 |
User-agent: |
Alpine 2.21 (DEB 202 2017-01-01) |
On Mon, 3 Dec 2018, Alfred M. Szmidt wrote:
> Git still isn't a requirement to be able to contribute to glibc or the
> rest of the GNU project, you can pull the e.g. tarball, make a patch,
> and send it to libc-alpha. The change might be applicable to master,
> it might not, but that is the same situation if you checked out a copy
> of the glibc from a year back.
You can do that, but if you want the patch to go on master it's making
things harder for yourself if you work only from the tarball. I think the
same applies with other limitations - such as if you ignore the list
archives and bug tracker when the history points to those being relevant,
or if you try to investigate the history using only some limited subset
statically extracted from it using a script rather than exploring the full
structured history data as appropriate for your issue.
I don't think such artificial limitations should be a significant
consideration in choosing tools and standards for GNU software
development. Use of distributed VCSes is good, but it's good because of
the increased power they provide in exploring history compared to
centralized systems, and because in general it's good for people to be
able to get their own copies of such metadata (people should be able to
fork the whole project if they wish, not need to rely on a single central
copy of any of the data), rather than because working mainly offline
without access to the hosted tools is an important consideration in
choosing development practices.
(If you want, you can rsync copies of the glibc list archives, and access
bug tracking data using the REST API, to get local copies of that data.)
--
Joseph S. Myers
address@hidden