-
Notifications
You must be signed in to change notification settings - Fork 18
AA: summarize removal flow #126
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
base: main
Are you sure you want to change the base?
Conversation
We discussed this in the meeting and ended up with a list that we also wanted to have in the docs. Signed-off-by: Christian Ehrhardt <[email protected]>
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.
Just a few nits, not blocking
@@ -162,6 +162,21 @@ about the package. | |||
Such bugs should be given a deadline of the end of the current release cycle, | |||
to ensure {term}`NBS` gets cleaned up before a stable release. | |||
|
|||
### Summarized flow of a removal consideration | |||
|
|||
Due to all these rules, when handling removal requests archive administrators roughly follow this flow: |
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.
Due to all these rules, when handling removal requests archive administrators roughly follow this flow: | |
Due to all these rules, when handling removal requests Archive Administrators generally follow this flow: |
1. If removed from Debian testing, but no other issue is known -> remove only if it blocks a transition or such in Ubuntu | ||
1. If it wasn't in Debian | ||
1. If it works fine and all it is violating is "being old" -> keep it | ||
1. If it works fine and the request is from the owner -> consider to remove it |
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.
1. If it works fine and the request is from the owner -> consider to remove it | |
1. If it works fine and the request is from the owner -> consider removing it |
1. If it wasn't in Debian | ||
1. If it works fine and all it is violating is "being old" -> keep it | ||
1. If it works fine and the request is from the owner -> consider to remove it | ||
1. If it works fine and the request is from the upstream -> consider to remove it |
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.
1. If it works fine and the request is from the upstream -> consider to remove it | |
1. If it works fine and the request is from the upstream -> consider removing it |
1. If it works fine, but is an FTBFS and gets no attention and thereby is hard to maintain once released -> file bug, add deadline, if not acted remove it | ||
1. If it is generally broken and unusable -> file bug, add deadline, if not acted remove it | ||
|
||
If unsure in either of these, bring it to the regular archive admin meeting or a channel for discussion and decision |
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.
If unsure in either of these, bring it to the regular archive admin meeting or a channel for discussion and decision | |
If unsure in either of these, bring it to the regular Archive Admin meeting or a channel for discussion and decision. |
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, @cpaelzer! A bunch of lang. nits.
@@ -162,6 +162,21 @@ about the package. | |||
Such bugs should be given a deadline of the end of the current release cycle, | |||
to ensure {term}`NBS` gets cleaned up before a stable release. | |||
|
|||
### Summarized flow of a removal consideration | |||
|
|||
Due to all these rules, when handling removal requests archive administrators roughly follow this flow: |
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.
Due to all these rules, when handling removal requests archive administrators roughly follow this flow: | |
Due to all these rules, when handling removal requests, Archive Administrators usually follow this flow: |
1. If already removed from Debian entirely -> we should probably remove it too (if the same reasons apply) | ||
1. If removed from Debian testing, but no other issue is known -> remove only if it blocks a transition or such in Ubuntu | ||
1. If it wasn't in Debian | ||
1. If it works fine and all it is violating is "being old" -> keep it |
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.
1. If it works fine and all it is violating is "being old" -> keep it | |
1. If it works fine, and all it is violating is "being old" -> keep it. |
1. If removed from Debian testing, but no other issue is known -> remove only if it blocks a transition or such in Ubuntu | ||
1. If it wasn't in Debian | ||
1. If it works fine and all it is violating is "being old" -> keep it | ||
1. If it works fine and the request is from the owner -> consider to remove it |
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.
1. If it works fine and the request is from the owner -> consider to remove it | |
1. If it works fine, and the request is from the owner -> consider removing it. |
1. If it wasn't in Debian | ||
1. If it works fine and all it is violating is "being old" -> keep it | ||
1. If it works fine and the request is from the owner -> consider to remove it | ||
1. If it works fine and the request is from the upstream -> consider to remove it |
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.
1. If it works fine and the request is from the upstream -> consider to remove it | |
1. If it works fine, and the request is from upstream -> consider removing it. |
1. If it works fine and all it is violating is "being old" -> keep it | ||
1. If it works fine and the request is from the owner -> consider to remove it | ||
1. If it works fine and the request is from the upstream -> consider to remove it | ||
1. If it works fine, but is an FTBFS and gets no attention and thereby is hard to maintain once released -> file bug, add deadline, if not acted remove it |
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.
1. If it works fine, but is an FTBFS and gets no attention and thereby is hard to maintain once released -> file bug, add deadline, if not acted remove it | |
1. If it works fine, but it's an {term}`FTBFS` and gets no attention and thereby is hard to maintain once released -> file a bug, add a deadline, and if it's not acted upon, remove it. |
|
||
1. If already removed from Debian entirely -> we should probably remove it too (if the same reasons apply) | ||
1. If removed from Debian testing, but no other issue is known -> remove only if it blocks a transition or such in Ubuntu | ||
1. If it wasn't in Debian |
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.
1. If it wasn't in Debian | |
1. If it wasn't in Debian: |
1. If it works fine and the request is from the owner -> consider to remove it | ||
1. If it works fine and the request is from the upstream -> consider to remove it | ||
1. If it works fine, but is an FTBFS and gets no attention and thereby is hard to maintain once released -> file bug, add deadline, if not acted remove it | ||
1. If it is generally broken and unusable -> file bug, add deadline, if not acted remove it |
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.
1. If it is generally broken and unusable -> file bug, add deadline, if not acted remove it | |
1. If it is generally broken and unusable -> file a bug, add a deadline, and if not acted upon, remove it. |
1. If it works fine, but is an FTBFS and gets no attention and thereby is hard to maintain once released -> file bug, add deadline, if not acted remove it | ||
1. If it is generally broken and unusable -> file bug, add deadline, if not acted remove it | ||
|
||
If unsure in either of these, bring it to the regular archive admin meeting or a channel for discussion and decision |
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.
If unsure in either of these, bring it to the regular archive admin meeting or a channel for discussion and decision | |
If unsure about any of these, bring it to the regular Archive Admin meeting or channel for discussion and decision. |
Oh, wonderful :-D A mid-air review collision, @s-makin :) |
We discussed this in the meeting and ended up with a list that we also wanted to have in the docs.