core-workflow
core-workflow copied to clipboard
python
Add `type-refactor` label
Although we discourage refactoring in general, there is sometimes a valid need for refactoring. Recent examples would be Irit's refactoring of the compiler and Mark Shannon's proposal for more readable type defs. We've historically also done (and are still doing) several test refactorings:
- python/cpython#54781
- python/cpython#93649
- python/cpython#108303
- python/cpython#123361
Currently, we use type-feature for these efforts, but it may be beneficial to be able to differentiate between (real^1) features and refactorings.
Some other examples:
- https://github.com/python/cpython/issues/129173
- https://github.com/python/cpython/issues/129928
- https://github.com/python/cpython/issues/128939
- https://github.com/python/cpython/issues/124697
There are probably more but this would at least separate what's a real feature from what's a refactorization (sometimes internal, sometimes not).
After https://github.com/python/cpython/issues/131238, and other issues that are meant to target refactorization-only (and not really feature), I become more and more convinced that we need such label.
@ezio-melotti Are you willing to create this new label? (I don't know which color to use though so I leave it to you, but maybe some purple? (in between the issue red and the blue feature))
Perhaps type-internal? If the goal is "to differentiate between [user-facing] features and refactorings".
type-internal would also be interesting! because sometimes it's more of an internal thing (and we coud use it for the different Tools that we don't ship it yet)
What other types of changes would type-internal encompass, apart from refactorings?
It could be something affecting the Tools for instance. I've opened the topic-tools label and saw that there were arguments in favor and against in a previous discussion. However, what we can probably safely say, is that whatever is in Tools is roughly something internal. Now, I don't know if mixing type-bug and type-internal would make sense to others or type-internal and type-feature in that case.
Nevertheless, I would be happy if we had a way to distinguish features from refactoring because most of the time, refactoring doesn't require a what's new and refactoring can be follow-ups of bug fixes, in which case those are not backported.
+1 to this type-refactor label.
I'd define it similar to "no visible behavior change, no non-internal API changes, no ABI changes" usually involving code reorganization to ease future work. Refactorings can sometimes be safe to backport which is something a feature does not do.
I think type-internal would be less useful. It doesn't communicate purpose as well. Ex: bugfixes and features can both be entirely internal, they just happen to also have a visible behavior change.
ISTM there is some support and little opposition for adding a type-refactor label. I suggest we add it and see how it fares. If it ends up being unused, we can just remove it.
Let's give it a week or two to see how it fares, then we can document it.
Would it be possible to choose a color different from the type-feature label? still blue, but a lighter blue? maybe #43A6C6?
I think light blue could get confused with the triaged label. How about something completely different? I don't think we have any good pink or yellow issue labels.
Let's give it a week or two to see how it fares, then we can document it.
I think it's worked well so far. I'm in favor of documenting it.