Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate hierarchical release notes #20

Closed
enisoc opened this issue Oct 17, 2017 · 8 comments
Closed

Generate hierarchical release notes #20

enisoc opened this issue Oct 17, 2017 · 8 comments
Assignees
Labels
sig/release Categorizes an issue or PR as relevant to SIG Release.

Comments

@enisoc
Copy link
Member

enisoc commented Oct 17, 2017

There is an effort underway to generate release notes from PRs, grouped by SIG and area labels. As the release team, we should engage with them to help test the tool and give feedback.

kubernetes/release#434
kubernetes/release#435

@enisoc enisoc added this to Prioritized Backlog in Kubernetes 1.9 Oct 17, 2017
@xiangpengzhao
Copy link
Contributor

ack. will join in the effort :)

@Bradamant3
Copy link

Bradamant3 commented Oct 17, 2017

This effort can really help only after we get better written release notes. I'd like to start with the content that the sigs produce in the first place. Editing after the fact, as previous releases have shown, is a great deal more work.
I'll add Nick Chase as an assignee after I learn his GH handle ...

@enisoc
Copy link
Member Author

enisoc commented Oct 17, 2017

@Bradamant3 That makes sense. What do you think is a good first step for improving the content? Publicizing a guide?

One way this hierarchical tool could help us improve content is by giving us a snapshot into the current relnotes, in a form that we can take to each SIG and give specific recommendations. For example, we could flag some sample relnotes as Good or Needs Improvement for each SIG, to show what we mean by quality content. The SIGs can then start to burn down their respective Needs Improvement lists. What do you think?

@Bradamant3
Copy link

cc @nickchase

@nickchase
Copy link
Contributor

@enisoc Editing after the fact can indeed be more work, but without this we'd need to do the writing from scratch anyway -- and without pre-sorted clues as to what's been accomplished -- so I think this can only help. But I agree that this is a good way for us to have something to go back to the SIGs with. It will also help us to see where we're either getting too many or too few release notes, IMO.

@Bradamant3
Copy link

Bradamant3 commented Oct 17, 2017

@enisoc @nickchase On my TODO list is putting together a guide, with template. (Here's a larger writeup, in case y'all haven't seen it): https://docs.google.com/document/d/17af5ZkRX83ISvizml9FKPc9TCtCIp9PecXpNGh324M8/edit#heading=h.ypeaydkz068g
I'll try to get something short and usable together in the next day or two, then maybe we can review and discuss the best way to take to sigs. I think probably the best we can do is get some subset of sigs on board for 1.9, and then go full out with better support with Jaice's ideas for 1.10.

@xiangpengzhao
Copy link
Contributor

BTW, the release note process of the bot has changed, I send two PRs to update PR template and docs:
kubernetes/kubernetes#54114
kubernetes/community#1221

@Bradamant3 PTAL. Thanks!

@enisoc enisoc moved this from Prioritized Backlog to Doing in Kubernetes 1.9 Nov 21, 2017
@enisoc enisoc moved this from Doing to Done in Kubernetes 1.9 Dec 11, 2017
@enisoc enisoc closed this as completed Dec 11, 2017
@enisoc
Copy link
Member Author

enisoc commented Dec 11, 2017

Hierarchical release notes were generated and used to seed the initial draft of the hand-curated notes.

@justaugustus justaugustus added the sig/release Categorizes an issue or PR as relevant to SIG Release. label Dec 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/release Categorizes an issue or PR as relevant to SIG Release.
Projects
No open projects
Development

No branches or pull requests

5 participants