2.26 hard freeze status

2.26 hard freeze status

[Siddhesh Poyarekar]

Hi,

As I mentioned before, I had planned to announce a hard freeze on master
on Thursday.  There is still one unresolved blocker though, i.e.
pr#21298.  Carlos, Torvald, any update on that?  If you're able to
resolve it on Thursday your time, we can go as planned, i.e. freeze at
midnight (EST instead of UTC as I had thought).  Otherwise we can
postpone the release by a day or two, let me know how much time you need.

Siddhesh

Re: 2.26 hard freeze status

[Florian Weimer]

On 07/27/2017 08:49 AM, Siddhesh Poyarekar wrote:
> Hi,
> 
> As I mentioned before, I had planned to announce a hard freeze on master
> on Thursday.  There is still one unresolved blocker though, i.e.
> pr#21298.  Carlos, Torvald, any update on that?  If you're able to
> resolve it on Thursday your time, we can go as planned, i.e. freeze at
> midnight (EST instead of UTC as I had thought).  Otherwise we can
> postpone the release by a day or two, let me know how much time you need.

We have a new ppc64le toolchain regression which we need to understand
before freezing (IMHO):

  https://sourceware.org/bugzilla/show_bug.cgi?id=21847

Thanks,
Florian

Re: 2.26 hard freeze status

[Siddhesh Poyarekar]

On Thursday 27 July 2017 05:01 PM, Florian Weimer wrote:
> We have a new ppc64le toolchain regression which we need to understand
> before freezing (IMHO):
> 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=21847

OK, I'm holding off the freeze for another day (I haven't heard from
Carlos or Torvald either and I'd like to give them another day to
respond while I go to sleep), which means that the release is now
tentatively on Wednesday.

Siddhesh

Re: 2.26 hard freeze status

[Carlos O'Donell]

On 07/27/2017 01:24 PM, Siddhesh Poyarekar wrote:
> On Thursday 27 July 2017 05:01 PM, Florian Weimer wrote:
>> We have a new ppc64le toolchain regression which we need to understand
>> before freezing (IMHO):
>>
>>   https://sourceware.org/bugzilla/show_bug.cgi?id=21847
> 
> OK, I'm holding off the freeze for another day (I haven't heard from
> Carlos or Torvald either and I'd like to give them another day to
> respond while I go to sleep), which means that the release is now
> tentatively on Wednesday.

I'm doing final testing of Torvald's patches for rwlock and robust
mutexes on ppc64, ppc64le, x86_64, i686, aarch64, and armv7hl to
make sure I have good coverage before commit.

I'm really trying to hit today as the day I commit these changes,
and so far I haven't seen any issue with the patch itself.

The one downside I have is that the reproducer doesn't reliably
reproduce the bug, and that's not a terrible problem, it's just
the kind of issue we face with P&C bugs.

-- 
Cheers,
Carlos.

Re: 2.26 hard freeze status

[Siddhesh Poyarekar]

On Thursday 27 July 2017 11:06 PM, Carlos O'Donell wrote:
> I'm doing final testing of Torvald's patches for rwlock and robust
> mutexes on ppc64, ppc64le, x86_64, i686, aarch64, and armv7hl to
> make sure I have good coverage before commit.
> 
> I'm really trying to hit today as the day I commit these changes,
> and so far I haven't seen any issue with the patch itself.
> 
> The one downside I have is that the reproducer doesn't reliably
> reproduce the bug, and that's not a terrible problem, it's just
> the kind of issue we face with P&C bugs.

That sounds good.  So when I wake up tomorrow and I see a definitive
comment on the ppc64le issue *and* Torvald's patch is committed, I'll
declare a freeze and release on Tuesday.  Otherwise we wait another day
and release on Wednesday.

Siddhesh

Re: 2.26 hard freeze status

[Torvald Riegel]

On Thu, 2017-07-27 at 23:12 +0530, Siddhesh Poyarekar wrote:
> On Thursday 27 July 2017 11:06 PM, Carlos O'Donell wrote:
> > I'm doing final testing of Torvald's patches for rwlock and robust
> > mutexes on ppc64, ppc64le, x86_64, i686, aarch64, and armv7hl to
> > make sure I have good coverage before commit.
> > 
> > I'm really trying to hit today as the day I commit these changes,
> > and so far I haven't seen any issue with the patch itself.
> > 
> > The one downside I have is that the reproducer doesn't reliably
> > reproduce the bug, and that's not a terrible problem, it's just
> > the kind of issue we face with P&C bugs.
> 
> That sounds good.  So when I wake up tomorrow and I see a definitive
> comment on the ppc64le issue *and* Torvald's patch is committed, I'll
> declare a freeze and release on Tuesday.  Otherwise we wait another day
> and release on Wednesday.

Thanks.  Carlos has committed the rwlock fix.

If you have a few spare cycles to review the patch I posted for 21778,
and there's still time because we haven't dealt with the ppc64le issue
yet, it would be good to include the fix for 21778 in the release.  It
is a regression caused by another robust mutex fix in the most recent
release.  Also, the patch is fix is pretty straightforward.

Re: 2.26 hard freeze status

[Carlos O'Donell]

On 07/28/2017 04:13 AM, Torvald Riegel wrote:
> On Thu, 2017-07-27 at 23:12 +0530, Siddhesh Poyarekar wrote:
>> On Thursday 27 July 2017 11:06 PM, Carlos O'Donell wrote:
>>> I'm doing final testing of Torvald's patches for rwlock and robust
>>> mutexes on ppc64, ppc64le, x86_64, i686, aarch64, and armv7hl to
>>> make sure I have good coverage before commit.
>>>
>>> I'm really trying to hit today as the day I commit these changes,
>>> and so far I haven't seen any issue with the patch itself.
>>>
>>> The one downside I have is that the reproducer doesn't reliably
>>> reproduce the bug, and that's not a terrible problem, it's just
>>> the kind of issue we face with P&C bugs.
>>
>> That sounds good.  So when I wake up tomorrow and I see a definitive
>> comment on the ppc64le issue *and* Torvald's patch is committed, I'll
>> declare a freeze and release on Tuesday.  Otherwise we wait another day
>> and release on Wednesday.
> 
> Thanks.  Carlos has committed the rwlock fix.
> 
> If you have a few spare cycles to review the patch I posted for 21778,
> and there's still time because we haven't dealt with the ppc64le issue
> yet, it would be good to include the fix for 21778 in the release.  It
> is a regression caused by another robust mutex fix in the most recent
> release.  Also, the patch is fix is pretty straightforward.
 
I'm going to start reviewing the robust mutex fix today.

My opinion on the ppc64le issue is that we should *not* wait for binutils
2.29 to get a fix. It is disappointing that a binutils release would go
out that had received so little testing that it breaks glibc, but we have
a time boxed release and we should stick to our time box.

With glibc releases we try hard to make sure glibc compiles properly with
new and old gcc, and new and old binutils, but it is not a hard and fast
rule that it should be compilable with all versions.

I believe that binutils 2.29 will have to receive more work over the
coming weeks to usable for distributions.

-- 
Cheers,
Carlos.

Re: 2.26 hard freeze status

[Siddhesh Poyarekar]

On Friday 28 July 2017 05:43 PM, Carlos O'Donell wrote:
> My opinion on the ppc64le issue is that we should *not* wait for binutils
> 2.29 to get a fix. It is disappointing that a binutils release would go
> out that had received so little testing that it breaks glibc, but we have
> a time boxed release and we should stick to our time box.
> 
> With glibc releases we try hard to make sure glibc compiles properly with
> new and old gcc, and new and old binutils, but it is not a hard and fast
> rule that it should be compilable with all versions.
> 
> I believe that binutils 2.29 will have to receive more work over the
> coming weeks to usable for distributions.

Sounds good, I'm going to announce a Friday midnight UTC freeze then if
that's enough time for you to review Torvald's fix and for him to push
it.  FWIW, I took a look at the patch and it looks pretty straightforward.

Release freeze is then on Tuesday night UTC and I'll do the release on
Wednesday my time.  That should give us a couple of days to cool off and
hope that nothing is broken badly in the meantime.

Siddhesh

Re: 2.26 hard freeze status

[Zack Weinberg]

On Fri, Jul 28, 2017 at 8:45 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> Release freeze is then on Tuesday night UTC and I'll do the release on
> Wednesday my time.  That should give us a couple of days to cool off and
> hope that nothing is broken badly in the meantime.

I'd like to ask for the ChangeLog to be rotated immediately after the
release.  We've made no progress on automatic generation of the darn
thing, and the current file is 10x larger than any of the previous
ones.

zw

Re: 2.26 hard freeze status

[Joseph Myers]

On Fri, 28 Jul 2017, Zack Weinberg wrote:

> On Fri, Jul 28, 2017 at 8:45 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> >
> > Release freeze is then on Tuesday night UTC and I'll do the release on
> > Wednesday my time.  That should give us a couple of days to cool off and
> > hope that nothing is broken badly in the meantime.
> 
> I'd like to ask for the ChangeLog to be rotated immediately after the
> release.  We've made no progress on automatic generation of the darn
> thing, and the current file is 10x larger than any of the previous
> ones.

I've just sent a message to bug-standards@gnu.org proposing no longer 
requiring ChangeLogs or commit logs in ChangeLog format when the 
conditions I proposed at 
<https://sourceware.org/ml/libc-alpha/2017-01/msg00041.html> are met.  I'd 
suggest people interested in issues relating to GNU Coding Standards 
requirements for ChangeLogs (as opposed to techniques for automatic 
generation in the existing format) should follow up there.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: 2.26 hard freeze status

[Carlos O'Donell]

On 07/28/2017 08:45 AM, Siddhesh Poyarekar wrote:
> On Friday 28 July 2017 05:43 PM, Carlos O'Donell wrote:
>> My opinion on the ppc64le issue is that we should *not* wait for binutils
>> 2.29 to get a fix. It is disappointing that a binutils release would go
>> out that had received so little testing that it breaks glibc, but we have
>> a time boxed release and we should stick to our time box.
>>
>> With glibc releases we try hard to make sure glibc compiles properly with
>> new and old gcc, and new and old binutils, but it is not a hard and fast
>> rule that it should be compilable with all versions.
>>
>> I believe that binutils 2.29 will have to receive more work over the
>> coming weeks to usable for distributions.
> 
> Sounds good, I'm going to announce a Friday midnight UTC freeze then if
> that's enough time for you to review Torvald's fix and for him to push
> it.  FWIW, I took a look at the patch and it looks pretty straightforward.
> 
> Release freeze is then on Tuesday night UTC and I'll do the release on
> Wednesday my time.  That should give us a couple of days to cool off and
> hope that nothing is broken badly in the meantime.

I've updated the wiki:

https://sourceware.org/glibc/wiki/Release/2.26

All blockers fixed.

Other issues moved to desirable.

Cheers,
Carlos.

Re: 2.26 hard freeze status

[Zack Weinberg]

On Fri, Jul 28, 2017 at 10:45 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 28 Jul 2017, Zack Weinberg wrote:
>>
>> I'd like to ask for the ChangeLog to be rotated immediately after the
>> release.  We've made no progress on automatic generation of the darn
>> thing, and the current file is 10x larger than any of the previous
>> ones.
>
> I've just sent a message to bug-standards@gnu.org proposing no longer
> requiring ChangeLogs or commit logs in ChangeLog format when the
> conditions I proposed at
> <https://sourceware.org/ml/libc-alpha/2017-01/msg00041.html> are met.  I'd
> suggest people interested in issues relating to GNU Coding Standards
> requirements for ChangeLogs (as opposed to techniques for automatic
> generation in the existing format) should follow up there.

Thank you for doing that.  I'm not sure I want to go all the way to
not even writing ChangeLog-like lists in the commit messages, mainly
because I find reading through the diff and composing a ChangeLog to
be a useful way of checking over my patches for silly mistakes, but
that's a detail.

However, the status quo is not going to change any time soon, so I
still would like glibc's ChangeLog to be rotated.

zw

Re: 2.26 hard freeze status

[Florian Weimer]

On 07/29/2017 06:19 PM, Zack Weinberg wrote:
> However, the status quo is not going to change any time soon, so I
> still would like glibc's ChangeLog to be rotated.
I would prefer that.  For me, the large ChangeLog file adds substantial
overhead when rsync'ing full trees (including the .git subdirectory).

Thanks,
Florian

Re: 2.26 hard freeze status

[Andreas Schwab]

On Jul 29 2017, Florian Weimer <fweimer@redhat.com> wrote:

> I would prefer that.  For me, the large ChangeLog file adds substantial
> overhead when rsync'ing full trees (including the .git subdirectory).

Why is that an overhead?  You have to transfer the data anyway, whether
it is in a single file or not.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 2.26 hard freeze status

[Florian Weimer]

On 07/29/2017 10:16 PM, Andreas Schwab wrote:
> On Jul 29 2017, Florian Weimer <fweimer@redhat.com> wrote:
> 
>> I would prefer that.  For me, the large ChangeLog file adds substantial
>> overhead when rsync'ing full trees (including the .git subdirectory).
> 
> Why is that an overhead?  You have to transfer the data anyway, whether
> it is in a single file or not.

rsync incremental transfers don't work for compressed ChangeLog file
objects in .git/.  Right now, they are fairly large (750 KB), and you
can easily have many of them if you keep rebasing a long patch series
which updates ChangeLog.

After the updates, those compressed objects would be significantly
smaller for quite some time because ChangeLog is much shorter.

Florian

Re: 2.26 hard freeze status

[Andreas Schwab]

On Jul 29 2017, Florian Weimer <fweimer@redhat.com> wrote:

> rsync incremental transfers don't work for compressed ChangeLog file
> objects in .git/.

And you can't switch to a git-aware transport?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 2.26 hard freeze status

[Siddhesh Poyarekar]

On Saturday 29 July 2017 09:49 PM, Zack Weinberg wrote:
> However, the status quo is not going to change any time soon, so I
> still would like glibc's ChangeLog to be rotated.

Sure, I'll do that when I open up master for 2.27.

Siddhesh

Re: 2.26 hard freeze status

[Florian Weimer]

On 07/29/2017 11:17 PM, Andreas Schwab wrote:
> On Jul 29 2017, Florian Weimer <fweimer@redhat.com> wrote:
> 
>> rsync incremental transfers don't work for compressed ChangeLog file
>> objects in .git/.
> 
> And you can't switch to a git-aware transport?

I'm not aware of anything which syncs a checkout and the .git
subdirectory, without having to commit everything first.

Thanks,
Florian

Re: 2.26 hard freeze status

[Andreas Schwab]

On Jul 31 2017, Florian Weimer <fweimer@redhat.com> wrote:

> I'm not aware of anything which syncs a checkout and the .git
> subdirectory, without having to commit everything first.

Transfer the repository with git and then sync the working tree by
whatever tool you prefer.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 2.26 hard freeze status

[Siddhesh Poyarekar]

On Friday 28 July 2017 07:20 PM, Zack Weinberg wrote:
> I'd like to ask for the ChangeLog to be rotated immediately after the
> release.  We've made no progress on automatic generation of the darn
> thing, and the current file is 10x larger than any of the previous
> ones.

Done.  I wonder if we should go all the way and tar up everything other
than ChangeLog and ChangeLog.1 into a ChangeLog.old.tar.gz.

Siddhesh

Re: 2.26 hard freeze status

[Joseph Myers]

On Wed, 2 Aug 2017, Siddhesh Poyarekar wrote:

> On Friday 28 July 2017 07:20 PM, Zack Weinberg wrote:
> > I'd like to ask for the ChangeLog to be rotated immediately after the
> > release.  We've made no progress on automatic generation of the darn
> > thing, and the current file is 10x larger than any of the previous
> > ones.
> 
> Done.  I wonder if we should go all the way and tar up everything other
> than ChangeLog and ChangeLog.1 into a ChangeLog.old.tar.gz.

When referring to the old history for which the ChangeLogs are useful, I 
think it's definitely best to have them as plain text files for immediate 
reference (meaning ChangeLog-1991, ChangeLog-1992 etc., split by year as 
GCC does, as my preferred arrangement).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: 2.26 hard freeze status

[Siddhesh Poyarekar]

On Wednesday 02 August 2017 08:55 PM, Joseph Myers wrote:
> When referring to the old history for which the ChangeLogs are useful, I 
> think it's definitely best to have them as plain text files for immediate 
> reference (meaning ChangeLog-1991, ChangeLog-1992 etc., split by year as 
> GCC does, as my preferred arrangement).

That's definitely better than the numbered ChangeLogs.

Siddhesh

Re: 2.26 hard freeze status

[Zack Weinberg]

On Wed, Aug 2, 2017 at 11:33 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> On Wednesday 02 August 2017 08:55 PM, Joseph Myers wrote:
>> When referring to the old history for which the ChangeLogs are useful, I
>> think it's definitely best to have them as plain text files for immediate
>> reference (meaning ChangeLog-1991, ChangeLog-1992 etc., split by year as
>> GCC does, as my preferred arrangement).
>
> That's definitely better than the numbered ChangeLogs.

To reduce clutter in the top level, how about a ChangeLog.old/
directory containing these?

zw

Re: 2.26 hard freeze status

[Joseph Myers]

On Wed, 2 Aug 2017, Zack Weinberg wrote:

> On Wed, Aug 2, 2017 at 11:33 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> > On Wednesday 02 August 2017 08:55 PM, Joseph Myers wrote:
> >> When referring to the old history for which the ChangeLogs are useful, I
> >> think it's definitely best to have them as plain text files for immediate
> >> reference (meaning ChangeLog-1991, ChangeLog-1992 etc., split by year as
> >> GCC does, as my preferred arrangement).
> >
> > That's definitely better than the numbered ChangeLogs.
> 
> To reduce clutter in the top level, how about a ChangeLog.old/
> directory containing these?

If we do that, it should have all the old ChangeLogs, including 
ChangeLog.old-ports* and nptl/ChangeLog.old and nptl_db/ChangeLog.old 
(appropriately named).  (I also think that unless and until we can stop 
using ChangeLogs, we should also move to using just the toplevel ChangeLog 
for all changes, including libidn and localedata, which would mean moving 
their existing files as well, but that's a separate issue.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Siddhesh Poyarekar]

On Wednesday 02 August 2017 11:36 PM, Joseph Myers wrote:
> If we do that, it should have all the old ChangeLogs, including 
> ChangeLog.old-ports* and nptl/ChangeLog.old and nptl_db/ChangeLog.old 
> (appropriately named).  (I also think that unless and until we can stop 
> using ChangeLogs, we should also move to using just the toplevel ChangeLog 
> for all changes, including libidn and localedata, which would mean moving 
> their existing files as well, but that's a separate issue.)

It makes sense to me, I'll make that directory and move all ChangeLog
files except the toplevel ChangeLog into it if nobody objects by the end
of the week.

To be clear, what is currently blocking us from not using the ChangeLog
file?  A reliable way to attribute authors and not just committers?  We
could start using the Signed-off-by mechanism for it if that works.  As
for bugs (since that is one good piece of information in the commit too)
we could use another Fixes: tag in the commit text.  Anything else?

Siddhesh

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Alan Modra]

On Thu, Aug 03, 2017 at 09:52:19AM +0530, Siddhesh Poyarekar wrote:
> To be clear, what is currently blocking us from not using the ChangeLog
> file?  A reliable way to attribute authors and not just committers?  We

git commit --amend --author="Joe Bloe <joe@bloe.org>" allows a
comitter to properly attribute authorship.  --date also lets you
change the commit date, so for example your own local commit that
languished without review for weeks can have the commit date updated
before pushing.  It might even be possible to have commit hooks modify
commit dates automatically.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Rical Jasan]

On 08/02/2017 09:22 PM, Siddhesh Poyarekar wrote:
> what is currently blocking us from not using the ChangeLog file?

I've been (re-)reading some of the arguments for it on bug-standards, to
try and appreciate the viewpoint, and it seems to be a feeling that the
ChangeLog is a consistent -- and persistent, when distributed with
release tarballs (which may be even more to the point) -- record, unlike
the VCS du jour.  Joseph may be able to provide better insight, though;
I'm not sure I've fully grasped all the subtleties of every concerned
party's arguments.  Only a handful have weighed in on the discussion
thus far.

Rical

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Florian Weimer]

On 08/03/2017 06:22 AM, Siddhesh Poyarekar wrote:
> To be clear, what is currently blocking us from not using the ChangeLog
> file?

The largest obstacle is that we currently do not have a culture of
reviewing commit message contents.  Dates are often wrong.  Authors
sometimes as well.  Some of the commit messages are excessive long.
Others do not even give a hint to what is being changed in the commit.
Most of the commits are perfectly acceptable (but slightly
inconsistent), but if we use the commit log as a data source for the
ChangeLog (or as a replacement), we'd have to improve things a bit, I think.

Thanks,
Florian

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Siddhesh Poyarekar]

On Thursday 03 August 2017 02:24 PM, Florian Weimer wrote:
> The largest obstacle is that we currently do not have a culture of
> reviewing commit message contents.  Dates are often wrong.  Authors
> sometimes as well.  Some of the commit messages are excessive long.
> Others do not even give a hint to what is being changed in the commit.
> Most of the commits are perfectly acceptable (but slightly
> inconsistent), but if we use the commit log as a data source for the
> ChangeLog (or as a replacement), we'd have to improve things a bit, I think.

I agree, and I hope that we improve over time as we shift focus from
reviewing the ChangeLog to reviewing the content of the commit message,
i.e. the email itself.  Perhaps automating commits (via patchwork,
gerrit, etc) is something that will aid this, but that could be a
separate discussion.

Siddhesh

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Siddhesh Poyarekar]

On Thursday 03 August 2017 11:36 AM, Alan Modra wrote:
> git commit --amend --author="Joe Bloe <joe@bloe.org>" allows a
> comitter to properly attribute authorship.  --date also lets you
> change the commit date, so for example your own local commit that
> languished without review for weeks can have the commit date updated
> before pushing.  It might even be possible to have commit hooks modify
> commit dates automatically.

Yes, but that does not cater for multiple authors.

I like the idea about commit hooks to modify the dates.

Siddhesh

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Siddhesh Poyarekar]

On Thursday 03 August 2017 11:49 AM, Rical Jasan wrote:
> I've been (re-)reading some of the arguments for it on bug-standards, to
> try and appreciate the viewpoint, and it seems to be a feeling that the
> ChangeLog is a consistent -- and persistent, when distributed with
> release tarballs (which may be even more to the point) -- record, unlike
> the VCS du jour.  Joseph may be able to provide better insight, though;
> I'm not sure I've fully grasped all the subtleties of every concerned
> party's arguments.  Only a handful have weighed in on the discussion
> thus far.

I personally don't see the consistency, persistence of the ChangeLog
format over the combination of plain English and code whose language I
am more familiar with than the ChangeLog format.

I guess it really boils down to a personal preference, so deciding on
this is going to be quite difficult in a consensus driven community like
ours.

Siddhesh

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Rical Jasan]

On 08/03/2017 02:23 AM, Siddhesh Poyarekar wrote:
> On Thursday 03 August 2017 11:49 AM, Rical Jasan wrote:
>> I've been (re-)reading some of the arguments for it on bug-standards, to
>> try and appreciate the viewpoint, and it seems to be a feeling that the
>> ChangeLog is a consistent -- and persistent, when distributed with
>> release tarballs (which may be even more to the point) -- record, unlike
>> the VCS du jour.  Joseph may be able to provide better insight, though;
>> I'm not sure I've fully grasped all the subtleties of every concerned
>> party's arguments.  Only a handful have weighed in on the discussion
>> thus far.
> 
> I personally don't see the consistency, persistence of the ChangeLog
> format over the combination of plain English and code whose language I
> am more familiar with than the ChangeLog format.

What struck me was the repeated sense of loss of history, in [1]:

"How would the information that is normally available in a ChangeLog
file be populated if all that information is in the VCS?  That would
still be needed for normal tarballs and the like when VCS is out the
window."

"History has a really bad memory, just because one uses a VCS today
doesn't mean that this will be available in 10, 20, 30 years in any
usable format, or it might vanish completley.

I've saved a few projects that used some sort of VCS, but was lost for
different reasons, and having had ChangeLog files would have saved many
many hours of headaches.  Now all that is left is a tarball, with no
information about who, when, or what was changed."

"If you put ChangeLog entries in the commit message, then yes this
information will be available.  But if you discard ChangeLog entries
completley, I do not see how it can be available.  ...  The information
also becomes totally lost as soon as you discard the VCS (i.e. when
doing releases)."

"It also makes a strong assumption on tools, and history has shown that
tools come and go but text files stay."


while I was trying to reconcile this comment, in [2]:

"People who keep suggesting git as a solution miss the point of being
able to extract this information in a archivable format."


[1] contains several other arguments I personally don't feel are valid;
e.g. (not all-inclusive):

"to be able to understand how something came to be one needs to look at
how things changed -- and only way to do that is with a ChangeLog entry."

""annotate", "diff" don't provide a human readable and searchable means
to go through history."

"the point of the ChangeLog files is to be able to undo changes."


but even though the ChangeLog isn't necessarily useful to me with a VCS,
the requirement that there has always been one and will always be one so
that a /consistent/ history of changes exists -- even if it isn't as
powerful as something like `git log' or `git bisect' -- is a compelling
enough argument that I don't have an immediate rebuttal.

Even in glibc, the project has used multiple VCS, but the ChangeLog
remains, throughout all the messy, un-bisectable, batch-committed
history, which is what I was alluding to by /persistent/.


> I guess it really boils down to a personal preference, so deciding on
> this is going to be quite difficult in a consensus driven community like
> ours.

Agreed.

Rical

[1] https://lists.gnu.org/archive/html/bug-standards/2017-07/msg00001.html
[2] https://lists.gnu.org/archive/html/bug-standards/2017-08/msg00001.html

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Siddhesh Poyarekar]

On Thursday 03 August 2017 03:45 PM, Rical Jasan wrote:
> What struck me was the repeated sense of loss of history, in [1]:
> 
> "How would the information that is normally available in a ChangeLog
> file be populated if all that information is in the VCS?  That would
> still be needed for normal tarballs and the like when VCS is out the
> window."
> 
> "History has a really bad memory, just because one uses a VCS today
> doesn't mean that this will be available in 10, 20, 30 years in any
> usable format, or it might vanish completley.
> 
> I've saved a few projects that used some sort of VCS, but was lost for
> different reasons, and having had ChangeLog files would have saved many
> many hours of headaches.  Now all that is left is a tarball, with no
> information about who, when, or what was changed."
> 
> "If you put ChangeLog entries in the commit message, then yes this
> information will be available.  But if you discard ChangeLog entries
> completley, I do not see how it can be available.  ...  The information
> also becomes totally lost as soon as you discard the VCS (i.e. when
> doing releases)."

The argument is self-contradictory, i.e. it talks about the idea that
VCS will be gone and that its data could not be relied upon, yet
considers it OK if ChangeLog entries are part of the commit message,
implying that there's something special in the ChangeLog format itself
that makes this OK.  Loss of VCS is a catastrophic scenario and a dump
of git log --stat at every release I think is a decent enough fallback
if that happens.

> "It also makes a strong assumption on tools, and history has shown that
> tools come and go but text files stay."
> 
> 
> while I was trying to reconcile this comment, in [2]:
> 
> "People who keep suggesting git as a solution miss the point of being
> able to extract this information in a archivable format."

Tools do come and go, but more importantly, they go because they have
evolved.  History consolidation from cvs/svn to git was flawed because
of our flawed usage of VCS where we dumped changes in batches instead of
separating logically distinct changes into smaller incremental patches
(something I insist on in my patch reviews) and not because of the
limitations of the tools themselves.

Anyway, I guess it is not correct to fork the discussion from the
bug-standards ML to here.  I would personally like to see the ChangeLog
go away as I see it as an unnecessary hurdle to contribution, but I
don't feel strongly enough about it at the moment to participate in that
discussion.

Siddhesh

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Siddhesh Poyarekar]

On Thursday 03 August 2017 03:57 PM, Siddhesh Poyarekar wrote:
> Anyway, I guess it is not correct to fork the discussion from the
> bug-standards ML to here.  I would personally like to see the ChangeLog
> go away as I see it as an unnecessary hurdle to contribution, but I
> don't feel strongly enough about it at the moment to participate in that
> discussion.

To clarify, I misunderstood Joseph's 5 point criteria as something that
was already agreed on and hence started the discussion on how we could
close the gap.  There doesn't seem to be a consensus on that yet.

Siddhesh

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Florian Weimer]

On 08/03/2017 12:15 PM, Rical Jasan wrote:
> but even though the ChangeLog isn't necessarily useful to me with a VCS,
> the requirement that there has always been one and will always be one so
> that a /consistent/ history of changes exists -- even if it isn't as
> powerful as something like `git log' or `git bisect' -- is a compelling
> enough argument that I don't have an immediate rebuttal.
> 
> Even in glibc, the project has used multiple VCS, but the ChangeLog
> remains, throughout all the messy, un-bisectable, batch-committed
> history, which is what I was alluding to by /persistent/.

I regularly have to do archaeology on the sources, and the ChangeLog
rarely contains useful information.  (The GNU standards require that it
is mechanically derived from the changes themselves, and the old glibc
code followed that.)  The ChangeLogs do point to the author, and while
many of them can be easily reached for comments, naturally they do not
remember what they did 15, 20 years ago and why. :-/

The bug tracker references in the ChangeLog are definitely helpful, but
only if the bug tracker is still around.  (The older ones refer to an
internal GNU or Cygnus tracker.)

Florian

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Joseph Myers]

On Thu, 3 Aug 2017, Siddhesh Poyarekar wrote:

> To be clear, what is currently blocking us from not using the ChangeLog
> file?  A reliable way to attribute authors and not just committers?  We
> could start using the Signed-off-by mechanism for it if that works.  As
> for bugs (since that is one good piece of information in the commit too)
> we could use another Fixes: tag in the commit text.  Anything else?

We need at least one of:

* A change to the GNU Coding Standards to stop requiring the ChangeLog 
format to be used in specified circumstances.  Join the discussion on 
bug-standards if interested in that.  This might need to be accompanied by 
e.g. appropriate conventions for crediting multi-author patches and for 
recording corrections to attribution information for commits without 
--author, or for other important corrections to commit messages (e.g. by 
subsequent empty commits whose commit messages state the corrections), and 
by technical measures such as shipping commit messages in tarballs or 
having versions of tarballs with the version history, if that's what ends 
up in the GNU Coding Standards.

* An agreed format for including ChangeLog-format information in commit 
messages so that a ChangeLog can be generated automatically (again, 
allowing for corrections), appropriate scripts to include that generated 
ChangeLog in releases, and git hooks to ensure the format is properly 
followed.

In both cases, more pre-commit review of commit messages than at present 
would be needed, and stronger requirements on having substantive commit 
messages.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Carlos O'Donell]

On 08/03/2017 07:22 AM, Joseph Myers wrote:
> In both cases, more pre-commit review of commit messages than at present 
> would be needed, and stronger requirements on having substantive commit 
> messages.

We presently review ChangeLogs are part of a patch submission, so I see
no real difference in reviewing the content of a proposed commit message.

If we moved towards linux-style review I think we could do worse, and the
kernel has already worked out a lot of these issues. For example by
accepting body of the email as the commit message, for having the ability
to use consistent tags (signed-off-by) to mark various types of behaviour
(including testing).

Enabling linux<->glibc cross collaboration by harmonizing our process
would be beneficial to both communities.

-- 
Cheers,
Carlos.

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Paul Eggert]

On 08/03/2017 04:22 AM, Joseph Myers wrote:
> We need at least one of:
>
> * A change to the GNU Coding Standards to stop requiring the ChangeLog
> format to be used in specified circumstances....
>
> * An agreed format for including ChangeLog-format information in commit
> messages so that a ChangeLog can be generated automatically (again,
> allowing for corrections)

Either will do. I've worked with projects that do the latter (e.g., 
Emacs, coreutils) and tend to agree that the hassles in 
automatically-generated ChangeLogs can be more trouble than they're 
worth. So I sent to bug-standards a specific proposal that would allow 
glibc to keep change descriptions in Git, while continuing to encourage 
the use of ChangeLog format for projects that do not establish and 
maintain their own formats. Please follow up on bug-standards as 
appropriate.

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Zack Weinberg]

On 08/03/2017 12:22 AM, Siddhesh Poyarekar wrote:
> On Wednesday 02 August 2017 11:36 PM, Joseph Myers wrote:
>> If we do that, it should have all the old ChangeLogs, including 
>> ChangeLog.old-ports* and nptl/ChangeLog.old and nptl_db/ChangeLog.old 
>> (appropriately named).  (I also think that unless and until we can stop 
>> using ChangeLogs, we should also move to using just the toplevel ChangeLog 
>> for all changes, including libidn and localedata, which would mean moving 
>> their existing files as well, but that's a separate issue.)
> 
> It makes sense to me, I'll make that directory and move all ChangeLog
> files except the toplevel ChangeLog into it if nobody objects by the end
> of the week.

There were no objections, but Siddhesh never got around to it either, so
I have done this now.  Here is the complete set of renames:

old name                          new name
--------                          --------
ChangeLog.1                       ChangeLog.old/ChangeLog.1
ChangeLog.10                      ChangeLog.old/ChangeLog.10
ChangeLog.11                      ChangeLog.old/ChangeLog.11
ChangeLog.12                      ChangeLog.old/ChangeLog.12
ChangeLog.13                      ChangeLog.old/ChangeLog.13
ChangeLog.14                      ChangeLog.old/ChangeLog.14
ChangeLog.15                      ChangeLog.old/ChangeLog.15
ChangeLog.16                      ChangeLog.old/ChangeLog.16
ChangeLog.17                      ChangeLog.old/ChangeLog.17
ChangeLog.18                      ChangeLog.old/ChangeLog.18
ChangeLog.2                       ChangeLog.old/ChangeLog.2
ChangeLog.3                       ChangeLog.old/ChangeLog.3
ChangeLog.4                       ChangeLog.old/ChangeLog.4
ChangeLog.5                       ChangeLog.old/ChangeLog.5
ChangeLog.6                       ChangeLog.old/ChangeLog.6
ChangeLog.7                       ChangeLog.old/ChangeLog.7
ChangeLog.8                       ChangeLog.old/ChangeLog.8
ChangeLog.9                       ChangeLog.old/ChangeLog.9
ChangeLog.old-ports               ChangeLog.old/ChangeLog.ports
ChangeLog.old-ports-aarch64       ChangeLog.old/ChangeLog.ports-aarch64
ChangeLog.old-ports-aix           ChangeLog.old/ChangeLog.ports-aix
ChangeLog.old-ports-alpha         ChangeLog.old/ChangeLog.ports-alpha
ChangeLog.old-ports-am33          ChangeLog.old/ChangeLog.ports-am33
ChangeLog.old-ports-arm           ChangeLog.old/ChangeLog.ports-arm
ChangeLog.old-ports-cris          ChangeLog.old/ChangeLog.ports-cris
ChangeLog.old-ports-hppa          ChangeLog.old/ChangeLog.ports-hppa
ChangeLog.old-ports-ia64          ChangeLog.old/ChangeLog.ports-ia64
ChangeLog.old-ports-linux-generic
ChangeLog.old/ChangeLog.ports-linux-generic
ChangeLog.old-ports-m68k          ChangeLog.old/ChangeLog.ports-m68k
ChangeLog.old-ports-microblaze    ChangeLog.old/ChangeLog.ports-microblaze
ChangeLog.old-ports-mips          ChangeLog.old/ChangeLog.ports-mips
ChangeLog.old-ports-powerpc       ChangeLog.old/ChangeLog.ports-powerpc
ChangeLog.old-ports-tile          ChangeLog.old/ChangeLog.ports-tile
nptl/ChangeLog.old                ChangeLog.old/ChangeLog.nptl
nptl_db/ChangeLog.old             ChangeLog.old/ChangeLog.nptl_db
libidn/ChangeLog                  ChangeLog.old/ChangeLog.libidn
localedata/ChangeLog              ChangeLog.old/ChangeLog.localedata

As suggested by Joseph, this includes libidn/ChangeLog and
localedata/ChangeLog; further changes to those directories should be
logged at top level.

zw

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[H.J. Lu]

On Fri, Sep 1, 2017 at 6:35 AM, Zack Weinberg <zackw@panix.com> wrote:
> On 08/03/2017 12:22 AM, Siddhesh Poyarekar wrote:
>> On Wednesday 02 August 2017 11:36 PM, Joseph Myers wrote:
>>> If we do that, it should have all the old ChangeLogs, including
>>> ChangeLog.old-ports* and nptl/ChangeLog.old and nptl_db/ChangeLog.old
>>> (appropriately named).  (I also think that unless and until we can stop
>>> using ChangeLogs, we should also move to using just the toplevel ChangeLog
>>> for all changes, including libidn and localedata, which would mean moving
>>> their existing files as well, but that's a separate issue.)
>>
>> It makes sense to me, I'll make that directory and move all ChangeLog
>> files except the toplevel ChangeLog into it if nobody objects by the end
>> of the week.
>
> There were no objections, but Siddhesh never got around to it either, so
> I have done this now.  Here is the complete set of renames:
>
> old name                          new name
> --------                          --------
> ChangeLog.1                       ChangeLog.old/ChangeLog.1
> ChangeLog.10                      ChangeLog.old/ChangeLog.10
> ChangeLog.11                      ChangeLog.old/ChangeLog.11
> ChangeLog.12                      ChangeLog.old/ChangeLog.12
> ChangeLog.13                      ChangeLog.old/ChangeLog.13
> ChangeLog.14                      ChangeLog.old/ChangeLog.14
> ChangeLog.15                      ChangeLog.old/ChangeLog.15
> ChangeLog.16                      ChangeLog.old/ChangeLog.16
> ChangeLog.17                      ChangeLog.old/ChangeLog.17
> ChangeLog.18                      ChangeLog.old/ChangeLog.18
> ChangeLog.2                       ChangeLog.old/ChangeLog.2
> ChangeLog.3                       ChangeLog.old/ChangeLog.3
> ChangeLog.4                       ChangeLog.old/ChangeLog.4
> ChangeLog.5                       ChangeLog.old/ChangeLog.5
> ChangeLog.6                       ChangeLog.old/ChangeLog.6
> ChangeLog.7                       ChangeLog.old/ChangeLog.7
> ChangeLog.8                       ChangeLog.old/ChangeLog.8
> ChangeLog.9                       ChangeLog.old/ChangeLog.9
> ChangeLog.old-ports               ChangeLog.old/ChangeLog.ports
> ChangeLog.old-ports-aarch64       ChangeLog.old/ChangeLog.ports-aarch64
> ChangeLog.old-ports-aix           ChangeLog.old/ChangeLog.ports-aix
> ChangeLog.old-ports-alpha         ChangeLog.old/ChangeLog.ports-alpha
> ChangeLog.old-ports-am33          ChangeLog.old/ChangeLog.ports-am33
> ChangeLog.old-ports-arm           ChangeLog.old/ChangeLog.ports-arm
> ChangeLog.old-ports-cris          ChangeLog.old/ChangeLog.ports-cris
> ChangeLog.old-ports-hppa          ChangeLog.old/ChangeLog.ports-hppa
> ChangeLog.old-ports-ia64          ChangeLog.old/ChangeLog.ports-ia64
> ChangeLog.old-ports-linux-generic
> ChangeLog.old/ChangeLog.ports-linux-generic
> ChangeLog.old-ports-m68k          ChangeLog.old/ChangeLog.ports-m68k
> ChangeLog.old-ports-microblaze    ChangeLog.old/ChangeLog.ports-microblaze
> ChangeLog.old-ports-mips          ChangeLog.old/ChangeLog.ports-mips
> ChangeLog.old-ports-powerpc       ChangeLog.old/ChangeLog.ports-powerpc
> ChangeLog.old-ports-tile          ChangeLog.old/ChangeLog.ports-tile
> nptl/ChangeLog.old                ChangeLog.old/ChangeLog.nptl
> nptl_db/ChangeLog.old             ChangeLog.old/ChangeLog.nptl_db
> libidn/ChangeLog                  ChangeLog.old/ChangeLog.libidn
> localedata/ChangeLog              ChangeLog.old/ChangeLog.localedata
>
> As suggested by Joseph, this includes libidn/ChangeLog and
> localedata/ChangeLog; further changes to those directories should be
> logged at top level.
>

These caused:

FAIL: posix/tst-regex
FAIL: posix/tst-regex2


-- 
H.J.

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 3956 bytes --]

On Fri, Sep 1, 2017 at 9:22 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Sep 1, 2017 at 6:35 AM, Zack Weinberg <zackw@panix.com> wrote:
>> On 08/03/2017 12:22 AM, Siddhesh Poyarekar wrote:
>>> On Wednesday 02 August 2017 11:36 PM, Joseph Myers wrote:
>>>> If we do that, it should have all the old ChangeLogs, including
>>>> ChangeLog.old-ports* and nptl/ChangeLog.old and nptl_db/ChangeLog.old
>>>> (appropriately named).  (I also think that unless and until we can stop
>>>> using ChangeLogs, we should also move to using just the toplevel ChangeLog
>>>> for all changes, including libidn and localedata, which would mean moving
>>>> their existing files as well, but that's a separate issue.)
>>>
>>> It makes sense to me, I'll make that directory and move all ChangeLog
>>> files except the toplevel ChangeLog into it if nobody objects by the end
>>> of the week.
>>
>> There were no objections, but Siddhesh never got around to it either, so
>> I have done this now.  Here is the complete set of renames:
>>
>> old name                          new name
>> --------                          --------
>> ChangeLog.1                       ChangeLog.old/ChangeLog.1
>> ChangeLog.10                      ChangeLog.old/ChangeLog.10
>> ChangeLog.11                      ChangeLog.old/ChangeLog.11
>> ChangeLog.12                      ChangeLog.old/ChangeLog.12
>> ChangeLog.13                      ChangeLog.old/ChangeLog.13
>> ChangeLog.14                      ChangeLog.old/ChangeLog.14
>> ChangeLog.15                      ChangeLog.old/ChangeLog.15
>> ChangeLog.16                      ChangeLog.old/ChangeLog.16
>> ChangeLog.17                      ChangeLog.old/ChangeLog.17
>> ChangeLog.18                      ChangeLog.old/ChangeLog.18
>> ChangeLog.2                       ChangeLog.old/ChangeLog.2
>> ChangeLog.3                       ChangeLog.old/ChangeLog.3
>> ChangeLog.4                       ChangeLog.old/ChangeLog.4
>> ChangeLog.5                       ChangeLog.old/ChangeLog.5
>> ChangeLog.6                       ChangeLog.old/ChangeLog.6
>> ChangeLog.7                       ChangeLog.old/ChangeLog.7
>> ChangeLog.8                       ChangeLog.old/ChangeLog.8
>> ChangeLog.9                       ChangeLog.old/ChangeLog.9
>> ChangeLog.old-ports               ChangeLog.old/ChangeLog.ports
>> ChangeLog.old-ports-aarch64       ChangeLog.old/ChangeLog.ports-aarch64
>> ChangeLog.old-ports-aix           ChangeLog.old/ChangeLog.ports-aix
>> ChangeLog.old-ports-alpha         ChangeLog.old/ChangeLog.ports-alpha
>> ChangeLog.old-ports-am33          ChangeLog.old/ChangeLog.ports-am33
>> ChangeLog.old-ports-arm           ChangeLog.old/ChangeLog.ports-arm
>> ChangeLog.old-ports-cris          ChangeLog.old/ChangeLog.ports-cris
>> ChangeLog.old-ports-hppa          ChangeLog.old/ChangeLog.ports-hppa
>> ChangeLog.old-ports-ia64          ChangeLog.old/ChangeLog.ports-ia64
>> ChangeLog.old-ports-linux-generic
>> ChangeLog.old/ChangeLog.ports-linux-generic
>> ChangeLog.old-ports-m68k          ChangeLog.old/ChangeLog.ports-m68k
>> ChangeLog.old-ports-microblaze    ChangeLog.old/ChangeLog.ports-microblaze
>> ChangeLog.old-ports-mips          ChangeLog.old/ChangeLog.ports-mips
>> ChangeLog.old-ports-powerpc       ChangeLog.old/ChangeLog.ports-powerpc
>> ChangeLog.old-ports-tile          ChangeLog.old/ChangeLog.ports-tile
>> nptl/ChangeLog.old                ChangeLog.old/ChangeLog.nptl
>> nptl_db/ChangeLog.old             ChangeLog.old/ChangeLog.nptl_db
>> libidn/ChangeLog                  ChangeLog.old/ChangeLog.libidn
>> localedata/ChangeLog              ChangeLog.old/ChangeLog.localedata
>>
>> As suggested by Joseph, this includes libidn/ChangeLog and
>> localedata/ChangeLog; further changes to those directories should be
>> logged at top level.
>>
>
> These caused:
>
> FAIL: posix/tst-regex
> FAIL: posix/tst-regex2
>

I checked in this patch to update tst-regex.c/tst-regex2.c for old ChangeLog
move.

-- 
H.J.

[-- Attachment #2: 0001-Update-tst-regex.c-tst-regex2.c-for-old-ChangeLog-mo.patch --]
[-- Type: text/x-patch, Size: 1964 bytes --]

From b30082799dfcd55ccbffce1dd74179d02ee1f41c Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Fri, 1 Sep 2017 10:20:49 -0700
Subject: [PATCH] Update tst-regex.c/tst-regex2.c for old ChangeLog move

	* posix/tst-regex.c (do_test): Replace "../ChangeLog.8" with
	"../ChangeLog.old/ChangeLog.8".
	* posix/tst-regex2.c (do_test): Replace "../ChangeLog.14" with
	"../ChangeLog.old/ChangeLog.14".
---
 ChangeLog          | 7 +++++++
 posix/tst-regex.c  | 2 +-
 posix/tst-regex2.c | 2 +-
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a142d38508..b06aeda7c7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
 2017-09-01  H.J. Lu  <hongjiu.lu@intel.com>
 
+	* posix/tst-regex.c (do_test): Replace "../ChangeLog.8" with
+	"../ChangeLog.old/ChangeLog.8".
+	* posix/tst-regex2.c (do_test): Replace "../ChangeLog.14" with
+	"../ChangeLog.old/ChangeLog.14".
+
+2017-09-01  H.J. Lu  <hongjiu.lu@intel.com>
+
 	* manual/contrib.texi: Credit Ulrich Drepper for the POSIX
 	Threads Library.
 
diff --git a/posix/tst-regex.c b/posix/tst-regex.c
index df2c108be5..90a8ccb088 100644
--- a/posix/tst-regex.c
+++ b/posix/tst-regex.c
@@ -67,7 +67,7 @@ do_test (void)
   mtrace ();
 
   /* Make the content of the file available in memory.  */
-  file = "../ChangeLog.8";
+  file = "../ChangeLog.old/ChangeLog.8";
   fd = open (file, O_RDONLY);
   if (fd == -1)
     error (EXIT_FAILURE, errno, "cannot open %s", basename (file));
diff --git a/posix/tst-regex2.c b/posix/tst-regex2.c
index 0d82c2acdd..5e624cb5c2 100644
--- a/posix/tst-regex2.c
+++ b/posix/tst-regex2.c
@@ -33,7 +33,7 @@ do_test (void)
     "((((((((((.?))))))))))((((((((((.?))))))))))((((((((((.?))))))))))"
     "((((((((((.?))))))))))Log\\.13" };
 
-  int fd = open ("../ChangeLog.14", O_RDONLY);
+  int fd = open ("../ChangeLog.old/ChangeLog.14", O_RDONLY);
   if (fd < 0)
     {
       printf ("Couldn't open ChangeLog.14: %m\n");
-- 
2.13.5

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Zack Weinberg]

On Fri, Sep 1, 2017 at 1:22 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Sep 1, 2017 at 9:22 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> These caused:
>>
>> FAIL: posix/tst-regex
>> FAIL: posix/tst-regex2
>>
>
> I checked in this patch to update tst-regex.c/tst-regex2.c for old ChangeLog
> move.

Thank you.

zw

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]

[Siddhesh Poyarekar]

On Friday 01 September 2017 10:52 PM, H.J. Lu wrote:
> I checked in this patch to update tst-regex.c/tst-regex2.c for old ChangeLog
> move.
> 
> 
<snip>
>    /* Make the content of the file available in memory.  */
> -  file = "../ChangeLog.8";
> +  file = "../ChangeLog.old/ChangeLog.8";
>    fd = open (file, O_RDONLY);
>    if (fd == -1)
>      error (EXIT_FAILURE, errno, "cannot open %s", basename (file));
> diff --git a/posix/tst-regex2.c b/posix/tst-regex2.c
> index 0d82c2acdd..5e624cb5c2 100644
> --- a/posix/tst-regex2.c
> +++ b/posix/tst-regex2.c
> @@ -33,7 +33,7 @@ do_test (void)
>      "((((((((((.?))))))))))((((((((((.?))))))))))((((((((((.?))))))))))"
>      "((((((((((.?))))))))))Log\\.13" };
>  
> -  int fd = open ("../ChangeLog.14", O_RDONLY);
> +  int fd = open ("../ChangeLog.old/ChangeLog.14", O_RDONLY);
>    if (fd < 0)
>      {
>        printf ("Couldn't open ChangeLog.14: %m\n");
> 

Instead, it might be cleaner to just copy those files to
tst-regex2-input.txt or similar.  We will likely run into this issue
again in another 5 years when all of us have forgotten about this ghost
dependency.

Siddhesh