[1/1,V2] manual/time.texi: correct the zoneinfo path

  The 'new' data directory path is about to have its
21st birthday. The info page needs to celebrate
with it.

glibc/ChangeLog.4:1828:
Sat Jul 16 00:42:30 1994  Roland McGrath  (roland@churchy.gnu.ai.mit.edu)
        * Makeconfig (datadir): Default to $(prefix)/share, not $(prefix)/lib.
        (sysconfdir): Variable renamed from etcdir.
glibc/ChangeLog.4:1709:
Fri Jul 29 01:50:37 1994  Roland McGrath  <roland@churchy.gnu.ai.mit.edu>
        * Version 1.08.4.

Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
 ChangeLog        | 5 +++++
 manual/time.texi | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)
  

On 02/01/2015 08:36 PM, J William Piggott wrote:
> 
> The 'new' data directory path is about to have its
> 21st birthday. The info page needs to celebrate
> with it.
> 
> glibc/ChangeLog.4:1828:
> Sat Jul 16 00:42:30 1994  Roland McGrath  (roland@churchy.gnu.ai.mit.edu)
>         * Makeconfig (datadir): Default to $(prefix)/share, not $(prefix)/lib.
>         (sysconfdir): Variable renamed from etcdir.
> glibc/ChangeLog.4:1709:
> Fri Jul 29 01:50:37 1994  Roland McGrath  <roland@churchy.gnu.ai.mit.edu>
>         * Version 1.08.4.
> 
> Signed-off-by: J William Piggott <elseifthen@gmx.com>

Applied.

We try to have bugs for all the user-visible changes we make,
so I created bug 17969 for this.

Cheers,
Carlos.
  

On 02/12/2015 10:24 PM, Carlos O'Donell wrote:
> 
> Applied.

Thank you Carlos.

Could you clarify one more thing for me please? The contribution
checklist says that Changelog entries should not be sent as a patch, but
I see that many people do so. Which is the preferred way?

Thank you,
William
  

On 02/13/2015 04:47 PM, J William Piggott wrote:
> On 02/12/2015 10:24 PM, Carlos O'Donell wrote:
>>
>> Applied.
> 
> Thank you Carlos.
> 
> Could you clarify one more thing for me please? The contribution
> checklist says that Changelog entries should not be sent as a patch, but
> I see that many people do so. Which is the preferred way?

To be honest, as a patch. I'm going to change the contribution checklist.
As a patch it allows me to use patchwork to pull down the patch, git am,
and then let my merge driver fix it up or fixup manually.

c.
  

> To be honest, as a patch. I'm going to change the contribution checklist.

A consensus of one?

> As a patch it allows me to use patchwork to pull down the patch, git am,
> and then let my merge driver fix it up or fixup manually.

The main reason it has always been policy not to include ChangeLog diffs in
a patch is that the context (i.e. top few lines of the file) always changes
and so the patch fails to apply.  If it does happen to apply because of
successful context matching, that puts the new log entry someplace other
than at the top of the line, which is not allowed.
  

On Fri, 13 Feb 2015, Roland McGrath wrote:

> > To be honest, as a patch. I'm going to change the contribution checklist.
> 
> A consensus of one?
> 
> > As a patch it allows me to use patchwork to pull down the patch, git am,
> > and then let my merge driver fix it up or fixup manually.
> 
> The main reason it has always been policy not to include ChangeLog diffs in
> a patch is that the context (i.e. top few lines of the file) always changes
> and so the patch fails to apply.  If it does happen to apply because of
> successful context matching, that puts the new log entry someplace other
> than at the top of the line, which is not allowed.

I also say that ChangeLog diffs should not appear in the patch.  Even if 
it's applied at the top because of custom merge handling, you still need 
to add the bug number to NEWS, and still need to update the date on the 
ChangeLog entry to reflect the date of commit, and still need to 
regenerate any generated files not included in the diff.
  

On 02/13/2015 06:16 PM, Roland McGrath wrote:
>> To be honest, as a patch. I'm going to change the contribution checklist.
> 
> A consensus of one?

Sorry, my intent was to simply start a new discussion on the topic.

>> As a patch it allows me to use patchwork to pull down the patch, git am,
>> and then let my merge driver fix it up or fixup manually.
> 
> The main reason it has always been policy not to include ChangeLog diffs in
> a patch is that the context (i.e. top few lines of the file) always changes
> and so the patch fails to apply.  If it does happen to apply because of
> successful context matching, that puts the new log entry someplace other
> than at the top of the line, which is not allowed.

Right.

The mean reason I want everything in the patch is so that I can do:

pwclient get XXX
patch -1 < foo.patch
or
git am foo.patch

Then I fixup ChangeLog quickly.

Alternatively I would have to cut and paste from foo.patch to
ChangeLog.

This discussion however is going to degenerate quickly into "Why
do we need ChangeLogs" and that's not a useful place to go.

I will instead take this time to look over again how to do ChangeLog
auto-generation from commit meta-data, to solve this problem more easily.

Cheers,
Carlos.
  

On Fri, 13 Feb 2015, Carlos O'Donell wrote:

> I will instead take this time to look over again how to do ChangeLog
> auto-generation from commit meta-data, to solve this problem more easily.

I advise looking at the gnulib gitlog-to-changelog script for that 
purpose.  Things to consider include the handling of commits with multiple 
authors for the ChangeLog entry, handling post-commit corrections 
(including to authors and dates), choice of date for the generated 
ChangeLog entries (commit date is probably better than author date, people 
rebasing sometimes end up pushing changes where the author date is months 
ago), handling the separate ChangeLogs still used for libidn and 
localedata, and distinguishing the long description of the rationale for a 
change (which should be included in the commit message, not just the 
summary line and ChangeLog entry) from the description of what changed 
that goes in the ChangeLog entry.

I'm not sure how much of that gitlog-to-changelog handles, but it seems a 
reasonable starting point.  And we could always consider such things as 
stopping using the remaining subdirectory ChangeLogs, or putting the full 
rationale in the generated ChangeLog rather than just the description of 
what changed, if desired.

(I suppose "make dist" could no longer use git archive unless the release 
process involves committing the generated ChangeLog before tagging / 
branching / releasing.)