-
Notifications
You must be signed in to change notification settings - Fork 381
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
considerations about enhancement tracking #539
Comments
/assign @tpepper @justaugustus /kind design |
+1000, all are really good proposals that will ease the burden of the release team as a whole, especially the roles of bug triage and enhancements. All of bug triage pre-freeze work can be clarified and automated with the above suggestions, and ease the ticket filtering during freeze and burndown with more organization by the feature owners and related SIGs - whether it is project boards, tracking issues, feature lifecycle document links etc. If the underlying organization is solid and the proper linking is done by feature owners themselves, there is no point for manual work by other people. This will give all the visibility that is needed. I suggest they're all implemented for v1.15 as they are and communicated in a clear way to all contributors to be aware. |
The format looks suspiciously like YAML, which brings into mind a whole plethora of release team aid scripts and automation to query and verify the release readiness. |
@neolit123 / @nikopen / @rosti -- you're all stumbling onto what we (SIG PM) had in mind for moving Enhancements Tracking forward. I'll write something detailed up when I'm back at a computer. |
interesting, could you please share VOD links (optionally timestamp) of when this was discussed? |
I'm torn, and I need to ruminate on this, b/c the purposes of keps was to get aggregate feature signal for a release, and it's clear we need to refine the process and automate the heck out of it. Right now we have a hybrid approach that lives in an "in-between" world. Ideally I would like KEPs to be the source of truth and contain enough meta-data so release owners can just parse. How SIGS do their work is up to them, but final read out imo should be a KEP PR with the punchlist done. I'm going to start tackling these sets of problems in the next quarter. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Since a release team hasn't implemented something, could tooling be build from somebody in Release Engineering? Or are alternatives such that we can close this? |
@justaugustus it seems like this is not priority critical urgent, can we demote it since there's been no work? |
please, note that i'm fine with closing this ticket especially after the discussion that alternative approaches can be taken. sadly, i forgot most of the details on this topic. |
/assign |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Hi, with this issue partially acted upon via #17473, what might be the remaining unresolved questions/to-do's on this issue? |
Hiya, circling back on my question ^^ |
hello, i saw the previous question too, but was hoping that one of the sig-release maintainers will reply.
it doesn't seem directly related. the idea here was to allow the release team to monitor the tracking issue progress via automation from a machine readable format. in any case i'm fine if this ticket is closed and if there are better ideas. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle rotten |
I think we can solve some parts of this issue with the Receipts KEP: kubernetes/enhancements#2167 / kubernetes/enhancements#2140 Let's close this for now and reopen if we feel that this should be addressed. |
@saschagrunert: Closing this issue. 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. |
introduction
each release, before feature freeze, the release team enhancement sub-team has the task to verify the status of pending features to be merged in k/kubernetes.
the team uses a google docs spread sheet that includes a lot of details like pending PRs, SIG owners, feature state and even some statistics.
each feature has a tracking issue located in the kuberenetes/enhancements (k/e) repository and after a recent change all features must also have a KEP, also located in the same repository.
problem statements
while attempting to obtain information about the current state-of-implementation of a certain feature, the release team has to post messages in k/e tracking issues, asking owners and maintainers:
what pending external to k/e tracking issues are there?
this topic is noisy because there is no standardization. every SIG uses a different schema for tracking their work. some use separate repositories, some use multiple issues for each item, some use a single tracking issue for each item.
proposal
the issue template has to be updated to include a list of tracking issues (or a single umbrella tracking issue). a list of tracking issues should look like this:
description of itemX
must match with an item in the KEP.kubernetes/kubernetes#1234567
is a tracking issue of an item.- [ ]
is a checkbox that indicates completion.what PRs are merged and what are yet to be created?
often times this question is hard to answer. multiple PR can accumulate over the course of the cycle for the exact same feature or work items. this can be very noisy and difficult to track by the release team.
proposal
PRs should not be an indication if a feature is "ready" for this release. tracking issues should be. the maintainer of the k/e main tracking issues should add checkmarks and links to the features that are completed. an external tracking issue and its PRs should cross reference. once all PRs are in the external tracking issue should be closed.
do you have documentation and test coverage?
arguable the hardest items to complete for a feature...
proposal
the proposal here is fairly simple. just extend the list to add tracking items for tests and documentation:
note that an Alpha state might not require a testing plan or documentation.
also that
website
andtest-infra
are just example locations. repos for tracking issues are matter of preference.is this feature going to "make it" this release?
a vague question for both sides, as those who are asking might not know what the feature does, while those who are questioned might not know if they can complete in time.
the feature lifecycle is undefined (or probably defined in a hard to find document).
if one googles "kubernetes feature lifecycle alpha beta ga" it gives them this link:
https://kubernetes.io/docs/reference/using-api/deprecation-policy/
proposal
the issue template from k/e should link to such a lifecycle document.
if such a document does not provide the following information, it should:
at this point, if a release team member sees the above list, verifies that all items are indeed closed and completed, there would be no need to ask questions even
examples of implementation lifecycles of a feature
other considerations:
handling subprojects
subprojects should not be treated in a special way (e.g. see "kubeadm" here and here).
all features that land in k/k should follow a standardized way of organization of the tracked issues.
links from k/e tracking issues could link to any GitHub issue.
project boards (alternative approach)
while SIGs such as Windows and API-Machinery are already using project boards for tracking their own work, they can be tricky with regards to:
while i definitely see the potential of using them, i went with the alternative approach of linking individual tracking issues. this approach is more linear and easy to follow by the release team, but requires more from the SIGs.
if SIG Release prefers project boards, we can go with this idea and link k/e tickets to project boards, but this requires some extra planning.
a problem with permissions
for both approaches, there is a problem with permissions. currently, only milestone maintainers can edit the k/e tickets (some of these rot with outdated information). while project boards also require a specific team to be able to edit. project boards win here in terms of flexibility, but again lack the linearity of the implementation timeline and edit history.
ideally the list of k/e ticket maintainers should be extended outside of milestone maintainers. milestone maintainers have the power to apply milestone in k/k while here we can have a separate group e.g. feature maintainers, which is a limited scope.
auto-pings vs human contact
often times developers are busy and/or they forget. so while we can continue to ping them in k/e tickets and slack, the general reminders can be automated in the lines of "hey, feature freeze is soon. please edit the OP of this document to include relevant items and/or update the status". if there is no follow up update after the automated message, human contact can follow on slack.
The text was updated successfully, but these errors were encountered: