Infrastructure/toddlers
3
0
Fork 0
Code Issues 10 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Implement Toddler for Handling Bugzilla Issues on Package Retirement and Unretirement #194

New issue
Open
opened 2024-05-29 13:03:53 +00:00 by jnsamyak · 6 comments
jnsamyak commented 2024-05-29 13:03:53 +00:00
Copy link

Description:

When a package is retired in Fedora, all Bugzilla issues filed for rawhide should be closed with the status "WONTFIX" or "EOL". Additionally, when a package is unretired, we need to notify the package maintainer with a list of all bugs that were closed due to the retirement, allowing them to handle the reopened bugs as they see fit.

Releng Ticket: https://pagure.io/releng/issue/8478

Requirements:

  • Bugzilla Closure on Package Retirement:
  1. Listen for messages indicating a package retirement.
  2. Identify all Bugzilla issues for the retired package filed for rawhide.
  3. Close these Bugzilla issues with the status "WONTFIX" or "EOL".
  • Notification on Package Unretirement:
  1. Listen for messages indicating a package unretirement.
  2. Retrieve the list of Bugzilla issues closed due to the previous retirement.
  3. Send a notification to the package maintainer with the list of closed bugs.

Automating this process will streamline the handling of Bugzilla issues related to package lifecycle events, reducing manual workload for maintainers and improving overall efficiency.

## Description: --- When a package is retired in Fedora, all Bugzilla issues filed for rawhide should be closed with the status "WONTFIX" or "EOL". Additionally, when a package is unretired, we need to notify the package maintainer with a list of all bugs that were closed due to the retirement, allowing them to handle the reopened bugs as they see fit. Releng Ticket: https://pagure.io/releng/issue/8478 ## Requirements: - Bugzilla Closure on Package Retirement: 1. Listen for messages indicating a package retirement. 2. Identify all Bugzilla issues for the retired package filed for rawhide. 3. Close these Bugzilla issues with the status "WONTFIX" or "EOL". - Notification on Package Unretirement: 1. Listen for messages indicating a package unretirement. 2. Retrieve the list of Bugzilla issues closed due to the previous retirement. 3. Send a notification to the package maintainer with the list of closed bugs. Automating this process will streamline the handling of Bugzilla issues related to package lifecycle events, reducing manual workload for maintainers and improving overall efficiency.
zlopez commented 2024-05-29 13:12:52 +00:00
Contributor
Copy link

This sounds like two new small toddlers that will just listen for topic and do some interactions with Bugzilla.

How the notification should be sent? By e-mail?

This sounds like two new small toddlers that will just listen for topic and do some interactions with Bugzilla. How the notification should be sent? By e-mail?
jnsamyak commented 2024-05-29 16:09:14 +00:00
Author
Copy link

How the notification should be sent? By e-mail?

I think so triggering an email against, should be the right way to go.

> How the notification should be sent? By e-mail? I think so triggering an email against, should be the right way to go.
kevin commented 2024-05-29 17:42:37 +00:00
Copy link

We shouldn't close with EOL, this is not end of life, it's a retirement.... I guess WONTFIX is best.

How do we get the list of bugs closed on unretirement? The only way I could think of is to perhaps add a whiteboard tag of some kind to them? but it would have to be a unique setting for that package so when we queried it later we wouldn't get other stuff. Or do you see some other way to get this information?

Perhaps we could leverage pagure for the notification? ie, when a unretirement is processed we add that list to the ticket and say it's processed?
(but I guess that could be bad if there's private bugs, so this might not be best)

We shouldn't close with EOL, this is not end of life, it's a retirement.... I guess WONTFIX is best. How do we get the list of bugs closed on unretirement? The only way I could think of is to perhaps add a whiteboard tag of some kind to them? but it would have to be a unique setting for that package so when we queried it later we wouldn't get other stuff. Or do you see some other way to get this information? Perhaps we could leverage pagure for the notification? ie, when a unretirement is processed we add that list to the ticket and say it's processed? (but I guess that could be bad if there's private bugs, so this might not be best)
jnsamyak commented 2024-06-03 03:40:17 +00:00
Author
Copy link

@churchyard's comment from the releng ticket:

The reviewer is supposed to check the bugzilla title matches the package.

The tool can then check if the repo name matches the bugzilla title, which it did in this case.
@churchyard's comment from the releng ticket: ``` The reviewer is supposed to check the bugzilla title matches the package. The tool can then check if the repo name matches the bugzilla title, which it did in this case. ```
churchyard commented 2024-06-03 10:39:23 +00:00
Contributor
Copy link

How is my comment relevant here?

How is my comment relevant here?
gotmax23 commented 2024-08-02 17:16:08 +00:00
Copy link

It would be nice to also leave an automatic comment on open distgiit PRs announcing that the package has been retired and pointing to the "how to unretire a package" docs.

It would be nice to also leave an automatic comment on open distgiit PRs announcing that the package has been retired and pointing to the "how to unretire a package" docs.
rcallwoo added this to the Unified backlog project 2025-08-07 01:50:39 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
master
staging
production
No results found.
Labels
Clear labels   
cpe

Tickets that should be addressed by CPE Team

  
EasyFix

Good first issue to start on

  
blocked

Indicates the work cannot proceed. There is a dependency or an issue that is preventing the team from completing the task. This is a flag for the Scrum Master to help unblock the team.

  
Bug

The software is not behaving as expected. It could be an error, a crash, or an incorrect result. Bugs often need to be prioritized based on their severity and business impact

  
Chore

Tasks that are necessary but don't directly deliver new value to the end-user. These are internal tasks like updating a library, managing user accounts, or setting up a new service.

  
Feature

It's something that a user would be able to see or interact with, such as a new button, a new page, or an improved workflow.

  
in-progress

This label is for work that a developer is actively working on. This is usually what you'll see on the "In Progress" column of your project board.

  
points:1

A task that is simple, small, and has very little uncertainty. It should be easy enough for any team member to pick up and complete quickly, without a lot of discussion or research.

  
points:13

Any task that feels like it's a "13" or more is considered an Epic. These are too large and uncertain to be worked on in a single sprint.

  
points:2

This is a task that is slightly more complex or larger than a "1." It might involve two or three simple steps, but the outcome is still very clear and there's little uncertainty.

  
points:3

medium-sized task with some noticeable complexity. It might require a bit more thought or collaboration. The steps are well-defined, but it's not a trivial change.

  
points:5

a significant piece of work. It has more complexity and a higher degree of uncertainty than smaller tasks. It might require some research, a design discussion, or collaboration across multiple teams.

  
points:8

complex task with a lot of uncertainty. It's often the largest size that a team will consider for a single sprint. It likely requires a detailed breakdown and multiple team members to complete.

  
priority:high

This is for work that is critical and needs to be addressed in the next sprint. It's often for urgent bugs, important features, or a major piece of technical debt that is blocking other work.

  
priority:low

This is for work that is good to do but not urgent. It's a candidate for being worked on when there's extra time or when it rises in importance. It can stay in the backlog for a longer period.

  
priority:medium

This is for important work that should be done soon, but isn't as urgent as a high-priority item. It will likely be considered for the next 1-2 sprints.

  
ready

indicates that an issue has been fully refined, has a story point value, and is ready to be pulled into a sprint. It has all the information needed for a developer to start working on it immediately.

  
review

This indicates that the work is complete, but it is now in a review state. This could mean a peer code review, a QA check, or a review by the Product Owner.

  
Technical Debt

work that improves the codebase without adding new features. It's work that pays down the "debt" you've accumulated, such as refactoring a messy piece of code, improving test coverage.

No labels
cpe
EasyFix
blocked
Bug
Chore
Feature
in-progress
points:1
points:13
points:2
points:3
points:5
points:8
priority:high
priority:low
priority:medium
ready
review
Technical Debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Unified backlog
Assignees
Clear assignees
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Infrastructure/toddlers#194
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?