-
-
Notifications
You must be signed in to change notification settings - Fork 165
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
Don't remove labels added manually #94
Comments
This is pretty tough to do. For the near term I could stop adding the python topic tag if you'd prefer. The reason it is tough is because there are cases where labels should be removed automatically, like when a branch changes to staging and has suddenly a huge diff. ofborg adds tons of labels, then the author rebases against staging and their commits become much smaller. Ofborg then correctly removes all the labels that are not appropriate. So, the reason this is tough is I think the feature is really: don't remove labels when a person added the label... and that is tough because GitHub's API makes it hard to see this information. Of course, maybe the right thing is to do is drop topic tagging altogether until I can do that? What do you think? |
cc @FRidh |
So, the reason this is tough is I think the feature is really: don't remove labels when a person added the label... and that is tough because GitHub's API makes it hard to see this information.
Well, if you turn this around — «the bot can remove only the labels set by the same bot» — the same specification sounds a bit more feasible. Borg could have a log of labels it has added (per PR/issue), and only remove the labels found in this log.
|
Or ofborg labels can have their own namespace |
No, please don't drop topic tagging :) |
@shlevy if multiple people start searching by |
True, @dotlambda! I forgot about that! Unfortunately the library I'm using to talk to GitHub (https://github.com/softprops/hubcaps) doesn't support it, so I'd have to first start by implementing that. I don't mind that, but it isn't something I'll be able to do straight away. If you don't mind waiting, I'd be happy to go this route. |
Sure, no need to hurry. Thanks for all your work, @grahamc! |
See for example NixOS/nixpkgs#36189
The text was updated successfully, but these errors were encountered: