[6.30] diverging branches of the release notes about root

[dpiparo]

I propose to close this issue as clarified: I agree that the solution is to make backporting as easy as possible (#14889) to avoid these cases. We can focus our attention to the automation.

[vepadulano]

Are there some common guidelines for the future on this? Like 'only do changes in 6.30 branch', or 'only do changes in master and then backport'?

I don't think we have a guideline yet for this very specific case. I think in practice, for the majority of cases we try to merge changes in master and then backport.

[ferdymercury]

Are there some common guidelines for the future on this? Like 'only do changes in 6.30 branch', or 'only do changes in master and then backport'?

I don't think we have a guideline yet for this very specific case. I think in practice, for the majority of cases we try to merge changes in master and then backport.

Let's imagine an example. I fix an issue for 6.32, and it is automatically collected and added to the 6.32 Release Notes. Furthermore i add a custom message to 6.32relnotes in the e.g. roofit section. I then backport the fix to 6.30. However, this time, the custom message in relnotes will not be automatically added to the 6.30 Release Notes because it was already released. So, after backporting the fix from master to 630, should one:

a) Create a new PR for the 630_ReleaseNotes file, but on the master branch and then after merging, backport it to 6.30 branch
or
b) Create a new PR for the 630_ReleaseNotes file and forget about the master branch, which will stay with an outdated version of 630-relnotes, which is however not very critical since the RelnotesWebpage for 6.30 is built from the 630 branch and not from master?

[pcanal]

it will not be automatically added to the 6.30 Release Notes because it was already released

This might not be specific enough. The release notes for the already released version of v6.30 (let's say v6.30.04) are frozen by definition. However the fix should be properly pickup by the release procedure for the next version, i.e. v6.30.06. (of course this require adding the proper tag to the issue). What am I missing?

[ferdymercury]

it will not be automatically added to the 6.30 Release Notes because it was already released

This might not be specific enough. The release notes for the already released version of v6.30 (let's say v6.30.04) are frozen by definition. However the fix should be properly pickup by the release procedure for the next version, i.e. v6.30.06. (of course this require adding the proper tag to the issue). What am I missing?

Thanks for the message.
True, but I did not express myself well (edited now above message). I am not speaking only about the automatic fixed issues collection protocol. I am speaking about manual additions to the release notes where a more in-depth message is written. In that case, there is the ambiguity of where this should be added, in the 63006relnotes of master and then backport to 630patches, or rather directly in 630patches. Right now, we have a bit of everything. If you use 'meld' to compare them, you will see the issue more clearly.