Write release lifecycle SOP for Quality team actions #895
Labels
No labels
agile
anacondawebui
arm
blockerfe
Closed As
Duplicate
Closed As
Fixed
Closed As
Invalid
Closed As
Wontfix
Closed As
Worksforme
coreos
criteria
defect
easyfix
enhancement
iot
meeting
meta
onboarding call
proventesters
retrospective
silverblue
sponsor
test cases
test days
wiki
ai-review-please
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
pr2jira
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
quality/tickets#895
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Releng has this rather good series of docs which covers the specific actions required at each stage of the release life cycle. It's not perfect, but it's useful.
We don't have anything like that. We have SOPs for doing specific things, but nothing that really says "at this point in the cycle Quality must do X". It's all in our heads. We should write it down!
Specific things to call out:
anything I'm missing?
Added "Publishing contributors stats"
I finally got around to starting on this today. So far I've got a high-level doc equivalent to https://docs.fedoraproject.org/en-US/infra/release_guide/release_process/ itself; I need to write some new individual task docs and link other existing ones, then turn the whole thing into a PR.
Didn't get around to this in sprint 11 either. Will bump it one more time.
OK, gonna drop this from sprint planning as I keep not getting to it. It's still a useful thing I should do, just...not 100% sure I'll get to it in the next sprint again.