1. Patchew
  2. Xen
  3. View series

[PATCH RFC for-4.19] docs/checklist: Start tagging new dev windows

Andrew Cooper posted 1 patch 3 months ago
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20240715164639.3378294-1-andrew.cooper3@citrix.com
docs/process/branching-checklist.txt          | 3 ++-
docs/process/release-technician-checklist.txt | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
[PATCH RFC for-4.19] docs/checklist: Start tagging new dev windows
Posted by Andrew Cooper 3 months ago 
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(-)

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
-- 
2.39.2
Re: [PATCH RFC for-4.19] docs/checklist: Start tagging new dev windows
Posted by Julien Grall 3 months ago 
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,


-- 
Julien Grall
Re: [PATCH RFC for-4.19] docs/checklist: Start tagging new dev windows
Posted by Jan Beulich 3 months ago 
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

Patchew 2.1-devel-b67e4c2

© 2016 - 2024 Red Hat, Inc.