-
Notifications
You must be signed in to change notification settings - Fork 222
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
[Code standards] Add detail on small PRs and Go packages #931
Conversation
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.
Looks great to me! 🎉 Very big fan of making standards like this clear, thanks @lbernick !
/approve
77c72be
to
e8c31ef
Compare
thanks @bobcatfish, just FYI I made a few changes clarifying our guidance around "releasable state" and partial feature development since you approved |
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.
😻
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.
Thanks @lbernick! Looks great! Just a minor comment.
@@ -160,33 +194,15 @@ what we want. | |||
* If possible, in addition to code snippets, include a reference to an end to end example | |||
* Ensure that all links and references are valid | |||
|
|||
## Functionality |
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 would suggest keeping this section -- we do want to always be able to cut a release and should avoid merging a PR that puts us in an unreleasable state.
For incremental addition of new features, the incremental changes need to be made in a way that is non-breaking and non-blocking -- such as flag guards and the like.
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 added a note that new features and api fields should be gated behind feature flags.
I agree we always want to be in an unreleasable state, but having this guidance in the code standards has caused some confusion since it's not clear how we'd get into an "unreleasable" state or what that actually means (thanks @XinruZhang for bringing this up!). I think it may be better to have specific guidance on what types of PRs to avoid. WDYT?
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'm not sure about removing this.
I think PR authors should ask themselves the question "if this was the last PR before the release, would we produce a usable release?". This is important to make sure that our nightly builds are usable as well as it helps very much in reducing the complexity the release manager may have to deal with.
Of course, CI takes a big role in ensuring that the code can be compiled and is generally safe and functionally sound. Feature flags help with incomplete features, but also documentation should be written so that it does not mislead users. We can try to make a complete list of all the things to consider, but I would prefer we still ask authors to ask themselves the question about the "releasable" state.
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.
A few affirmative guidelines and / or antipatterns that I can think of:
- No PR should require concurrent release of code in another repository
- No PR should require that a release be held pending some later PR
- No PR should include a breaking change without either (1) a controlling feature flag or (2) a release note that explains the intentionality of the breaking change
- A PR that intentionally changes functionality should only be merged along with compatible, passing tests in the same PR
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.
Thanks for the discussion here! I brought back the note about "unreleasable state" with a bit more explanation. @bendory I included all your examples but changed the third to "PRs must adhere to the project's API stability policy." I think it would be good as a follow up to move most of the contents of https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md that aren't specific to pipelines into the community repo so that all projects can link them.
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.
/LGTM
modulo one minor nit in a separate comment
aab9bf2
to
3aaf3ba
Compare
@bendory: changing LGTM is restricted to collaborators 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. |
@bobcatfish @vdemeester would either of you mind giving a LGTM please? |
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.
Thank a lot @lbernick - this looks good - only I disagree about removing the part about "releasable" state completely.
@@ -160,33 +194,15 @@ what we want. | |||
* If possible, in addition to code snippets, include a reference to an end to end example | |||
* Ensure that all links and references are valid | |||
|
|||
## Functionality |
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'm not sure about removing this.
I think PR authors should ask themselves the question "if this was the last PR before the release, would we produce a usable release?". This is important to make sure that our nightly builds are usable as well as it helps very much in reducing the complexity the release manager may have to deal with.
Of course, CI takes a big role in ensuring that the code can be compiled and is generally safe and functionally sound. Feature flags help with incomplete features, but also documentation should be written so that it does not mislead users. We can try to make a complete list of all the things to consider, but I would prefer we still ask authors to ask themselves the question about the "releasable" state.
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.
Thanks for the updates @lbernick - it looks good to me now!
/approve
@@ -160,33 +194,15 @@ what we want. | |||
* If possible, in addition to code snippets, include a reference to an end to end example | |||
* Ensure that all links and references are valid | |||
|
|||
## Functionality |
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.
/LGTM
modulo one minor nit in a separate comment
@bendory: changing LGTM is restricted to collaborators 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. |
This commit updates code standards to include guidance on pull request size, structuring Go packages, and better release notes. It also improves language around being in a "releasable state" and what kinds of PRs put us in an unreleasable state.
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afrittoli, bendory, bobcatfish, jerop, vdemeester, XinruZhang 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 |
This commit updates code standards to include guidance on pull request size, structuring Go packages, and better release notes.
It also removes language around being in a "releasable state".
It's difficult to write a PR that puts us in an unreleasable state, since our CI prevents this,
so guidance that PRs shouldn't put us in an unreleasable state adds confusion.