Move ChangeLog to ChangeLog.old/ChangeLog.19
diff mbox series

Message ID 87wode75tm.fsf@oldenburg2.str.redhat.com
State New
Headers show
Series
  • Move ChangeLog to ChangeLog.old/ChangeLog.19
Related show

Commit Message

Florian Weimer Oct. 9, 2019, 7:09 a.m. UTC
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%)

Comments

Gabriel F. T. Gomes Oct. 9, 2019, 1:23 p.m. UTC | #1
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. UTC | #2
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. UTC | #3
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. UTC | #4
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. UTC | #5
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. UTC | #6
* 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. UTC | #7
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. UTC | #8
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. UTC | #9
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. UTC | #10
* 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. UTC | #11
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. UTC | #12
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. UTC | #13
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. UTC | #14
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. UTC | #15
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. UTC | #16
* 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. UTC | #17
* 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. UTC | #18
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. UTC | #19
* 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. UTC | #20
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 mbox series

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