| Message ID | 87wode75tm.fsf@oldenburg2.str.redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | Move ChangeLog to ChangeLog.old/ChangeLog.19 | expand |
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
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).
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
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
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
* 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
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>
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
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>.
* 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
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.
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
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.
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.
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
* 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
* 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
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,
* 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
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.
diff --git a/ChangeLog b/ChangeLog.old/ChangeLog.19
similarity index 100%
rename from ChangeLog
rename to ChangeLog.old/ChangeLog.19
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%)