| Message ID | 20240715164639.3378294-1-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC,for-4.19] docs/checklist: Start tagging new dev windows | expand |
Hi Andrew, On 15/07/2024 17:46, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> With one remark below: Reviewed-by: Julien Grall <jgrall@amazon.com> > --- > CC: Jan Beulich <JBeulich@suse.com> > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: Julien Grall <julien@xen.org> > CC: Oleksii Kurochko <oleksii.kurochko@gmail.com> > > This is about figuring out when a change was first introduced. Take > 10b719dc88 for example (completely random pick). > > The right answer is `git tag --contains $sha` and look for the oldest > RELEASE-$X. In this case it's Xen 4.6, but the tags are not numerically > sorted so the answer is towards the end of the list of 166 tags. > > The better answer would be to `git describe $sha` because git has an algorithm > to do this nicely. In this case, it's 4.5.0-rc4-934-g10b719dc8830 because we > branch first and tag RELEASE-4.6.0 on the branch, rather than releasing off > master. > > With 0082626f35af (opening of the 4.6 tree) containing an annotated tag of > 4.6-dev, git describe now gives 4.6-dev-902-g10b719dc8830 which far more > helpful when doing code archeology. I think some of this explanation should be in the commit message. > > I propose that we retroactively tag each commit which opened a new dev > tree (the commit which changes the version number) > > Looking back in history, Keir did used to tag the point that the tree > branched, but that seems to have stopped when moving from HG to git. > > Thoughts? > --- > docs/process/branching-checklist.txt | 3 ++- > docs/process/release-technician-checklist.txt | 2 ++ > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/docs/process/branching-checklist.txt b/docs/process/branching-checklist.txt > index 3dfa8ec2570b..b2bb9ac1fa00 100644 > --- a/docs/process/branching-checklist.txt > +++ b/docs/process/branching-checklist.txt > @@ -79,7 +79,8 @@ The variables and there content should be: > Where X.Y is the release version (e.g. 4.17). > > Update newly diverging staging (unstable) according to > -release-technician-checklist.txt section re README etc. > +release-technician-checklist.txt section re README etc., > +including tagging the new dev window. > > Update newly diverging staging-$v according to > release-technician-checklist.txt section re README etc., > diff --git a/docs/process/release-technician-checklist.txt b/docs/process/release-technician-checklist.txt > index e6db02b87585..7d2d90e57e7b 100644 > --- a/docs/process/release-technician-checklist.txt > +++ b/docs/process/release-technician-checklist.txt > @@ -79,6 +79,8 @@ t=RELEASE-$r > # - xen/Kconfig.debug > # config DEBUG > # default n > +# > +# - tag staging branch for the new dev window. e.g. 4.20-dev > > * tag xen-unstable > > > base-commit: 1ddc8c1bad93aa6cbfe616dd72333460c47f96c9 > prerequisite-patch-id: 2ea535e6248ebf47b5db0c59db0f4fcfc7a74cf9 Cheers,
On 15.07.2024 18:58, Julien Grall wrote: > On 15/07/2024 17:46, Andrew Cooper wrote: >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > > With one remark below: > > Reviewed-by: Julien Grall <jgrall@amazon.com> > >> --- >> CC: Jan Beulich <JBeulich@suse.com> >> CC: Stefano Stabellini <sstabellini@kernel.org> >> CC: Julien Grall <julien@xen.org> >> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com> >> >> This is about figuring out when a change was first introduced. Take >> 10b719dc88 for example (completely random pick). >> >> The right answer is `git tag --contains $sha` and look for the oldest >> RELEASE-$X. In this case it's Xen 4.6, but the tags are not numerically >> sorted so the answer is towards the end of the list of 166 tags. >> >> The better answer would be to `git describe $sha` because git has an algorithm >> to do this nicely. In this case, it's 4.5.0-rc4-934-g10b719dc8830 because we >> branch first and tag RELEASE-4.6.0 on the branch, rather than releasing off >> master. >> >> With 0082626f35af (opening of the 4.6 tree) containing an annotated tag of >> 4.6-dev, git describe now gives 4.6-dev-902-g10b719dc8830 which far more >> helpful when doing code archeology. > > I think some of this explanation should be in the commit message. Imo it could even be moved up verbatim. Jan
diff --git a/docs/process/branching-checklist.txt b/docs/process/branching-checklist.txt index 3dfa8ec2570b..b2bb9ac1fa00 100644 --- a/docs/process/branching-checklist.txt +++ b/docs/process/branching-checklist.txt @@ -79,7 +79,8 @@ The variables and there content should be: Where X.Y is the release version (e.g. 4.17). Update newly diverging staging (unstable) according to -release-technician-checklist.txt section re README etc. +release-technician-checklist.txt section re README etc., +including tagging the new dev window. Update newly diverging staging-$v according to release-technician-checklist.txt section re README etc., diff --git a/docs/process/release-technician-checklist.txt b/docs/process/release-technician-checklist.txt index e6db02b87585..7d2d90e57e7b 100644 --- a/docs/process/release-technician-checklist.txt +++ b/docs/process/release-technician-checklist.txt @@ -79,6 +79,8 @@ t=RELEASE-$r # - xen/Kconfig.debug # config DEBUG # default n +# +# - tag staging branch for the new dev window. e.g. 4.20-dev * tag xen-unstable
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> CC: Stefano Stabellini <sstabellini@kernel.org> CC: Julien Grall <julien@xen.org> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com> This is about figuring out when a change was first introduced. Take 10b719dc88 for example (completely random pick). The right answer is `git tag --contains $sha` and look for the oldest RELEASE-$X. In this case it's Xen 4.6, but the tags are not numerically sorted so the answer is towards the end of the list of 166 tags. The better answer would be to `git describe $sha` because git has an algorithm to do this nicely. In this case, it's 4.5.0-rc4-934-g10b719dc8830 because we branch first and tag RELEASE-4.6.0 on the branch, rather than releasing off master. With 0082626f35af (opening of the 4.6 tree) containing an annotated tag of 4.6-dev, git describe now gives 4.6-dev-902-g10b719dc8830 which far more helpful when doing code archeology. I propose that we retroactively tag each commit which opened a new dev tree (the commit which changes the version number) Looking back in history, Keir did used to tag the point that the tree branched, but that seems to have stopped when moving from HG to git. Thoughts? --- docs/process/branching-checklist.txt | 3 ++- docs/process/release-technician-checklist.txt | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) base-commit: 1ddc8c1bad93aa6cbfe616dd72333460c47f96c9 prerequisite-patch-id: 2ea535e6248ebf47b5db0c59db0f4fcfc7a74cf9