Release note targeting for multiple branches

[david-mcmahon]

There's no way to target different release note states for multiple branches due to the fact that the release note state is based on the one source PR, not the individual cherry-picks.

For example, #27861 seems like a good release note for 1.3 but we don't want it as a relnote for 1.2.5 (since it was rolled back).

The fix probably entails checking the cherry-pick for a release note state and letting it override the source PRs state and then updating the cherry-pick doc to allow for that in these special circumstances. I can't immediately think of any issues with that approach.

It will mean more processing time and github polling to check labels for both PRs for every merge pull.

cc @eparis @roberthbailey

[erictune]

Can the release note generator detect rolled back changes?

On Fri, Jun 24, 2016 at 5:23 PM, David McMahon notifications@github.com
wrote:

There's no way to target different release note states for multiple
branches due to the fact that the release note state is based on the one
source PR, not the individual cherry-picks.

For example, #27861 seems like a good release note for 1.3 but we don't
want it as a relnote for 1.2.5 (since it was rolled back).

The fix probably entails checking the cherry-pick for a release note state
and letting it override the source PRs state and then updating the
cherry-pick doc to allow for that in these special circumstances. I can't
immediately think of any issues with that approach.

It will mean more processing time and github polling to check labels for
both PRs for every merge pull.

cc @eparis https://github.com/eparis @roberthbailey
https://github.com/roberthbailey

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17, or mute the thread
https://github.com/notifications/unsubscribe/AHuudn7OQU52I6BIsxqmXJkWhWbzcBQoks5qPHUNgaJpZM4I-OGe
.

[david-mcmahon]

@erictune No. I had considered adding that, but then our canonical method for exposing release notes is through labeling and that single interface provides more flexibility in deciding what should or should not be captured as a release note (rollback spanned releases, rollback itself was relevant for capturing the fact that a feature didn't make it in a release, etc). Adding more moving parts here might confuse things.

[fejta-bot]

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[roberthbailey]

/sig release

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close