Patchwork Move ChangeLog to ChangeLog.old/ChangeLog.19

login
register
mail settings
Submitter Florian Weimer
Date Oct. 9, 2019, 7:09 a.m.
Message ID <87wode75tm.fsf@oldenburg2.str.redhat.com>
Download mbox | patch
Permalink /patch/34886/
State New
Headers show

Comments

Florian Weimer - Oct. 9, 2019, 7:09 a.m.
We no longer maintain a manually-written ChangeLog file:

  <https://sourceware.org/ml/libc-alpha/2019-09/msg00333.html>
  <https://sourceware.org/ml/libc-alpha/2019-10/msg00131.html>

Instead the release manager is expected to generate a ChangeLog-like
file using scripts/gitlog_to_changelog.py.  For further details,
see commit f2144b7874b23be7c7eb184ec601633ec6fa8fac ("Script to
generate ChangeLog-like output from git log").
---
 ChangeLog => ChangeLog.old/ChangeLog.19 | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename ChangeLog => ChangeLog.old/ChangeLog.19 (100%)
Gabriel F. T. Gomes - Oct. 9, 2019, 1:23 p.m.
I support this change and the stop of manually-written ChangeLog
entries when this patch lands as a commit in the repository.  Taking into
account what Joseph raised in a different thread [1], I suppose that such
commit could be documented as the beginning of the range for automatic
ChangeLog generation *for this specific cycle*, where both manually and
automatically generated ChangeLog entries will coexist.  For future
cycles, I don't know how to document it.

[1] https://sourceware.org/ml/libc-alpha/2019-10/msg00223.html

On 09 Oct 2019, Florian Weimer wrote:

>We no longer maintain a manually-written ChangeLog file:
>
>  <https://sourceware.org/ml/libc-alpha/2019-09/msg00333.html>
>  <https://sourceware.org/ml/libc-alpha/2019-10/msg00131.html>
>
>Instead the release manager is expected to generate a ChangeLog-like
>file using scripts/gitlog_to_changelog.py.  For further details,
>see commit f2144b7874b23be7c7eb184ec601633ec6fa8fac ("Script to
>generate ChangeLog-like output from git log").
>---
> ChangeLog => ChangeLog.old/ChangeLog.19 | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename ChangeLog => ChangeLog.old/ChangeLog.19 (100%)
>
>diff --git a/ChangeLog b/ChangeLog.old/ChangeLog.19
>similarity index 100%
>rename from ChangeLog
>rename to ChangeLog.old/ChangeLog.19
Joseph Myers - Oct. 9, 2019, 4:18 p.m.
On Wed, 9 Oct 2019, Gabriel F. T. Gomes wrote:

> I support this change and the stop of manually-written ChangeLog
> entries when this patch lands as a commit in the repository.  Taking into
> account what Joseph raised in a different thread [1], I suppose that such
> commit could be documented as the beginning of the range for automatic
> ChangeLog generation *for this specific cycle*, where both manually and
> automatically generated ChangeLog entries will coexist.  For future
> cycles, I don't know how to document it.

My expectation for would be that the automatic ChangeLog generation is 
always the last one before tagging and branching (so for future cycles 
it's run for commits from the last release tag up to HEAD at that point, 
whereas for this cycle the starting commit would be the point at which we 
renamed the manually written ChangeLog, not the previous release tag).
Siddhesh Poyarekar - Oct. 9, 2019, 6:05 p.m.
On 09/10/19 12:18 pm, Joseph Myers wrote:
> On Wed, 9 Oct 2019, Gabriel F. T. Gomes wrote:
> 
>> I support this change and the stop of manually-written ChangeLog
>> entries when this patch lands as a commit in the repository.  Taking into
>> account what Joseph raised in a different thread [1], I suppose that such
>> commit could be documented as the beginning of the range for automatic
>> ChangeLog generation *for this specific cycle*, where both manually and
>> automatically generated ChangeLog entries will coexist.  For future
>> cycles, I don't know how to document it.
> 
> My expectation for would be that the automatic ChangeLog generation is 
> always the last one before tagging and branching (so for future cycles 
> it's run for commits from the last release tag up to HEAD at that point, 
> whereas for this cycle the starting commit would be the point at which we 
> renamed the manually written ChangeLog, not the previous release tag).

I think I understand your position now, thank you for explaining it.  I
will generate the ChangeLog from Florian's commit up to latest HEAD as
part of the release process, commit it and then tag glibc-2.31.

Siddhesh
Tulio Magno Quites Machado Filho - Oct. 11, 2019, 7:18 p.m.
Siddhesh Poyarekar <siddhesh@gotplt.org> writes:

> On 09/10/19 12:18 pm, Joseph Myers wrote:
>> On Wed, 9 Oct 2019, Gabriel F. T. Gomes wrote:
>> 
>>> I support this change and the stop of manually-written ChangeLog
>>> entries when this patch lands as a commit in the repository.  Taking into
>>> account what Joseph raised in a different thread [1], I suppose that such
>>> commit could be documented as the beginning of the range for automatic
>>> ChangeLog generation *for this specific cycle*, where both manually and
>>> automatically generated ChangeLog entries will coexist.  For future
>>> cycles, I don't know how to document it.
>> 
>> My expectation for would be that the automatic ChangeLog generation is 
>> always the last one before tagging and branching (so for future cycles 
>> it's run for commits from the last release tag up to HEAD at that point, 
>> whereas for this cycle the starting commit would be the point at which we 
>> renamed the manually written ChangeLog, not the previous release tag).
>
> I think I understand your position now, thank you for explaining it.  I
> will generate the ChangeLog from Florian's commit up to latest HEAD as
> part of the release process, commit it and then tag glibc-2.31.

I think this requires changes to the wiki page with the Release Process.

Is this describing what you had in mind?
https://sourceware.org/glibc/wiki/Release?action=diff&rev2=184&rev1=183
Siddhesh Poyarekar - Oct. 11, 2019, 7:21 p.m.
On 11/10/19 3:18 pm, Tulio Magno Quites Machado Filho wrote:
> I think this requires changes to the wiki page with the Release Process.
> 
> Is this describing what you had in mind?
> https://sourceware.org/glibc/wiki/Release?action=diff&rev2=184&rev1=183
> 

That looks good.  I didn't see Florian's patch go through though.

Siddhesh
Florian Weimer - Oct. 11, 2019, 7:26 p.m.
* Siddhesh Poyarekar:

> On 11/10/19 3:18 pm, Tulio Magno Quites Machado Filho wrote:
>> I think this requires changes to the wiki page with the Release Process.
>> 
>> Is this describing what you had in mind?
>> https://sourceware.org/glibc/wiki/Release?action=diff&rev2=184&rev1=183
>> 
>
> That looks good.  I didn't see Florian's patch go through though.

It did not.  I'm still waiting for comments.

Thanks,
Florian
Carlos O'Donell - Oct. 11, 2019, 7:31 p.m.
On 10/9/19 3:09 AM, Florian Weimer wrote:
> We no longer maintain a manually-written ChangeLog file:
> 
>   <https://sourceware.org/ml/libc-alpha/2019-09/msg00333.html>
>   <https://sourceware.org/ml/libc-alpha/2019-10/msg00131.html>
> 
> Instead the release manager is expected to generate a ChangeLog-like
> file using scripts/gitlog_to_changelog.py.  For further details,
> see commit f2144b7874b23be7c7eb184ec601633ec6fa8fac ("Script to
> generate ChangeLog-like output from git log").
> ---
>  ChangeLog => ChangeLog.old/ChangeLog.19 | 0
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  rename ChangeLog => ChangeLog.old/ChangeLog.19 (100%)
> 
> diff --git a/ChangeLog b/ChangeLog.old/ChangeLog.19
> similarity index 100%
> rename from ChangeLog
> rename to ChangeLog.old/ChangeLog.19
 
This looks good to me.

Lets me throw away 4 ChangeLog changes I've been updating *daily*
while I do work because I want to be ready to push them :-)

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Siddhesh Poyarekar - Oct. 11, 2019, 7:34 p.m.
On 11/10/19 3:26 pm, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> On 11/10/19 3:18 pm, Tulio Magno Quites Machado Filho wrote:
>>> I think this requires changes to the wiki page with the Release Process.
>>>
>>> Is this describing what you had in mind?
>>> https://sourceware.org/glibc/wiki/Release?action=diff&rev2=184&rev1=183
>>>
>>
>> That looks good.  I didn't see Florian's patch go through though.
> 
> It did not.  I'm still waiting for comments.

I think this is good to go.

Siddhesh
Joseph Myers - Oct. 11, 2019, 7:57 p.m.
On Fri, 11 Oct 2019, Tulio Magno Quites Machado Filho wrote:

> I think this requires changes to the wiki page with the Release Process.
> 
> Is this describing what you had in mind?
> https://sourceware.org/glibc/wiki/Release?action=diff&rev2=184&rev1=183

I think the new step should come *after* the updates to version.h and 
features.h, just before tagging, so that those header updates appear at 
the top of the generated ChangeLog.

I think the instructions will need to say explicitly what to use in place 
of glibc-2.30 when generating the ChangeLog for 2.31.

After the second tag (the post-release one) has been created, there needs 
to be a step of moving the generated ChangeLog to 
ChangeLog.old/ChangeLog.<next-number>.
Florian Weimer - Oct. 11, 2019, 8:02 p.m.
* Joseph Myers:

> On Wed, 9 Oct 2019, Gabriel F. T. Gomes wrote:
>
>> I support this change and the stop of manually-written ChangeLog
>> entries when this patch lands as a commit in the repository.  Taking into
>> account what Joseph raised in a different thread [1], I suppose that such
>> commit could be documented as the beginning of the range for automatic
>> ChangeLog generation *for this specific cycle*, where both manually and
>> automatically generated ChangeLog entries will coexist.  For future
>> cycles, I don't know how to document it.
>
> My expectation for would be that the automatic ChangeLog generation is 
> always the last one before tagging and branching (so for future cycles 
> it's run for commits from the last release tag up to HEAD at that point, 
> whereas for this cycle the starting commit would be the point at which we 
> renamed the manually written ChangeLog, not the previous release tag).

We are debating off-list whether you are in favor of renaming the
ChangeLog *now*, or want to delay that to a future date.  Would you
please clarify?

Thanks,
Florian
Joseph Myers - Oct. 11, 2019, 8:21 p.m.
On Fri, 11 Oct 2019, Florian Weimer wrote:

> > My expectation for would be that the automatic ChangeLog generation is 
> > always the last one before tagging and branching (so for future cycles 
> > it's run for commits from the last release tag up to HEAD at that point, 
> > whereas for this cycle the starting commit would be the point at which we 
> > renamed the manually written ChangeLog, not the previous release tag).
> 
> We are debating off-list whether you are in favor of renaming the
> ChangeLog *now*, or want to delay that to a future date.  Would you
> please clarify?

I support renaming it now, and making the wiki documentation of the 
release process name the relevant commit as the starting point for 
ChangeLog generation for the 2.31 release.
Siddhesh Poyarekar - Oct. 11, 2019, 8:25 p.m.
On 11/10/19 4:21 pm, Joseph Myers wrote:
> I support renaming it now, and making the wiki documentation of the 
> release process name the relevant commit as the starting point for 
> ChangeLog generation for the 2.31 release.
> 

This is a pretty significant change in our processes, so just adding a
tag (changelogs-end-here or similar) may not be a bad idea IMO.  It
doesn't have to be a signed tag since it is not really release-critical.

Siddhesh
Joseph Myers - Oct. 11, 2019, 8:27 p.m.
On Fri, 11 Oct 2019, Siddhesh Poyarekar wrote:

> On 11/10/19 4:21 pm, Joseph Myers wrote:
> > I support renaming it now, and making the wiki documentation of the 
> > release process name the relevant commit as the starting point for 
> > ChangeLog generation for the 2.31 release.
> > 
> 
> This is a pretty significant change in our processes, so just adding a
> tag (changelogs-end-here or similar) may not be a bad idea IMO.  It
> doesn't have to be a signed tag since it is not really release-critical.

If we add a tag, it specifically should *not* be an annotated tag because 
that would affect "git describe" output.
Tulio Magno Quites Machado Filho - Oct. 11, 2019, 8:50 p.m.
Joseph Myers <joseph@codesourcery.com> writes:

> On Fri, 11 Oct 2019, Tulio Magno Quites Machado Filho wrote:
>
>> I think this requires changes to the wiki page with the Release Process.
>> 
>> Is this describing what you had in mind?
>> https://sourceware.org/glibc/wiki/Release?action=diff&rev2=184&rev1=183
>
> I think the new step should come *after* the updates to version.h and 
> features.h, just before tagging, so that those header updates appear at 
> the top of the generated ChangeLog.

Ack.

> I think the instructions will need to say explicitly what to use in place 
> of glibc-2.30 when generating the ChangeLog for 2.31.

I didn't understand your proposal.
What do you think that needs to be explicit in this example for glibc 2.31?

    ./scripts/gitlog_to_changelog.py glibc-2.30 HEAD > ChangeLog

> After the second tag (the post-release one) has been created, there needs 
> to be a step of moving the generated ChangeLog to 
> ChangeLog.old/ChangeLog.<next-number>.

Ack.
Siddhesh Poyarekar - Oct. 11, 2019, 8:56 p.m.
On 11/10/19 4:50 pm, Tulio Magno Quites Machado Filho wrote:
> I didn't understand your proposal.
> What do you think that needs to be explicit in this example for glibc 2.31?
> 
>     ./scripts/gitlog_to_changelog.py glibc-2.30 HEAD > ChangeLog
> 

For 2.31, this should be:

  ./scripts/gitlog_to_changelog.py changelogs-end-here HEAD > ChangeLog

For all other revs it should be:

  ./scripts/gitlog_to_changelog.py glibc-2.<rev-1> HEAD > ChangeLog

Siddhesh
Florian Weimer - Oct. 11, 2019, 8:58 p.m.
* Joseph Myers:

> On Fri, 11 Oct 2019, Florian Weimer wrote:
>
>> > My expectation for would be that the automatic ChangeLog generation is 
>> > always the last one before tagging and branching (so for future cycles 
>> > it's run for commits from the last release tag up to HEAD at that point, 
>> > whereas for this cycle the starting commit would be the point at which we 
>> > renamed the manually written ChangeLog, not the previous release tag).
>> 
>> We are debating off-list whether you are in favor of renaming the
>> ChangeLog *now*, or want to delay that to a future date.  Would you
>> please clarify?
>
> I support renaming it now, and making the wiki documentation of the 
> release process name the relevant commit as the starting point for 
> ChangeLog generation for the 2.31 release.

Thank you for the clarification.  Pushed.

I also added a lightweight tag, changelog-ends-here.  Thanks for the
suggestion that we shouldn't use an annotated tag for that.  I had to
tag directly on sourceware, to bypass the update hooks, that's why there
is no notification on glibc-cvs.  I verified that the non-annotated tag
is propagated by a git clone.

Florian
Florian Weimer - Oct. 11, 2019, 9:47 p.m.
* Siddhesh Poyarekar:

> On 11/10/19 4:50 pm, Tulio Magno Quites Machado Filho wrote:
>> I didn't understand your proposal.
>> What do you think that needs to be explicit in this example for glibc 2.31?
>> 
>>     ./scripts/gitlog_to_changelog.py glibc-2.30 HEAD > ChangeLog
>> 
>
> For 2.31, this should be:
>
>   ./scripts/gitlog_to_changelog.py changelogs-end-here HEAD > ChangeLog

Nit: I called the tag “changelog-ends-here” (given that the file name is
in the singular).

Thanks,
Florian
Tulio Magno Quites Machado Filho - Oct. 15, 2019, 2:28 p.m.
Florian Weimer <fweimer@redhat.com> writes:

> * Siddhesh Poyarekar:
>
>> On 11/10/19 4:50 pm, Tulio Magno Quites Machado Filho wrote:
>>> I didn't understand your proposal.
>>> What do you think that needs to be explicit in this example for glibc 2.31?
>>> 
>>>     ./scripts/gitlog_to_changelog.py glibc-2.30 HEAD > ChangeLog
>>> 
>>
>> For 2.31, this should be:
>>
>>   ./scripts/gitlog_to_changelog.py changelogs-end-here HEAD > ChangeLog
>
> Nit: I called the tag “changelog-ends-here” (given that the file name is
> in the singular).

I've just updated the instructions based on this discussion:
https://sourceware.org/glibc/wiki/Release?action=diff&rev2=185&rev1=183

Thanks,
Florian Weimer - Oct. 15, 2019, 2:36 p.m.
* Tulio Magno Quites Machado Filho:

> Florian Weimer <fweimer@redhat.com> writes:
>
>> * Siddhesh Poyarekar:
>>
>>> On 11/10/19 4:50 pm, Tulio Magno Quites Machado Filho wrote:
>>>> I didn't understand your proposal.
>>>> What do you think that needs to be explicit in this example for glibc 2.31?
>>>> 
>>>>     ./scripts/gitlog_to_changelog.py glibc-2.30 HEAD > ChangeLog
>>>> 
>>>
>>> For 2.31, this should be:
>>>
>>>   ./scripts/gitlog_to_changelog.py changelogs-end-here HEAD > ChangeLog
>>
>> Nit: I called the tag “changelog-ends-here” (given that the file name is
>> in the singular).
>
> I've just updated the instructions based on this discussion:
> https://sourceware.org/glibc/wiki/Release?action=diff&rev2=185&rev1=183

Thanks, looks good.

Florian
Joseph Myers - Oct. 15, 2019, 3:18 p.m.
On Tue, 15 Oct 2019, Tulio Magno Quites Machado Filho wrote:

> Florian Weimer <fweimer@redhat.com> writes:
> 
> > * Siddhesh Poyarekar:
> >
> >> On 11/10/19 4:50 pm, Tulio Magno Quites Machado Filho wrote:
> >>> I didn't understand your proposal.
> >>> What do you think that needs to be explicit in this example for glibc 2.31?
> >>> 
> >>>     ./scripts/gitlog_to_changelog.py glibc-2.30 HEAD > ChangeLog
> >>> 
> >>
> >> For 2.31, this should be:
> >>
> >>   ./scripts/gitlog_to_changelog.py changelogs-end-here HEAD > ChangeLog
> >
> > Nit: I called the tag “changelog-ends-here” (given that the file name is
> > in the singular).
> 
> I've just updated the instructions based on this discussion:
> https://sourceware.org/glibc/wiki/Release?action=diff&rev2=185&rev1=183

Thanks, the instructions now look as I'd expect.

Patch

diff --git a/ChangeLog b/ChangeLog.old/ChangeLog.19
similarity index 100%
rename from ChangeLog
rename to ChangeLog.old/ChangeLog.19