-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Go workspaces blog post (take 2) #45626
Conversation
@thockin - can you explain in the PR description why we're making this change? /lgtm /hold PR description isn't clear; ideally, clarify and then unhold |
✅ Pull request preview available for checking
To edit notification comments on pull requests, go to your Netlify site configuration. |
LGTM label has been added. Git tree hash: d73e6e0dcaa772e4845018486ad7fbe95e5c6810
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sftim The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Do I need to fix the date? |
I don't have context about the article yank; to me, it was fine to publish as-was. |
@thockin thanks so much for resubmitting this blog! It was also great to meet you at KubeCon 🚀
Can you please set the publication date for April 19, 2024? |
--- | ||
|
||
**Author:** Tim Hockin (Google) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add some text to explain that this is reposting the content published in March at https://www.k8s.dev/blog/2024/03/19/go-workspaces-in-kubernetes/
I don't understand our overall intent here; the improvement is great, but it's already delivered and end users won't notice it. We can have it as a post-release blog article but I don't understand why we would.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to be published post-release because it was handled and tracked by the Release Comms team as a feature blog. It should not have been published without their knowledge or without them assigning a publication date. The original PR included all of that context. We reverted because it was, to the Release Team, an unauthorized early publication.
If it should never have been a feature blog and thus should never have been under the control of Release Comms, that's fine and it can be published whenever you and @thockin please, but as long as Release Comms owns it, Release Comms needs to be kept in the loop and approve of publication.
No objection to removing this from Release Comms ownership if it's regarding a feature that is already live and they don't have a problem with it, but everyone has to be informed of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I truly truly do not care and am happy to roll with . It's not a "feature" of 1.30 - it's in the codebase now and any developer using k/k is subject to it. That said, it was a KEP and tracked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We (The 1.30 Comms team) tracked it in the 1.30 project board and scheduled it as a feature blog due to it being a KEP. As previously stated, we just need someone to inform us whether or not this is remaining with the Comms Team as a feature blog.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the less clueful - it's already published at https://www.k8s.dev/blog/2024/03/19/go-workspaces-in-kubernetes/ - so if we say this is NOT a feature blog, do I just close this PR and be done? Any other implications?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the less clueful - it's already published at https://www.k8s.dev/blog/2024/03/19/go-workspaces-in-kubernetes/ - so if we say this is NOT a feature blog, do I just close this PR and be done? Any other implications?
I think we just close it and leave the contributor site article published. I don't think it's a post-release blog because the improvement isn't awaiting the upcoming v1.30 release.
Any objections to that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have no objections, go ahead and close it.
New changes are detected. LGTM label has been removed. |
Re-pushed with feedback |
/close We'll keep https://www.k8s.dev/blog/2024/03/19/go-workspaces-in-kubernetes/ |
@sftim: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
A blog post on Go workspaces in k/k
Replay of #45358, revert #45625 - apparently we jumped the gun and had to revert it. This restores it.
/cc @katcosgrove @natalisucks @sftim