-
Notifications
You must be signed in to change notification settings - Fork 27
add tag: regression
#106
Comments
Isn't that pretty much also covered by |
I think P.S. From my experience this distinction is commonly used to prioritize issues. |
To use an analogy, in most places I worked in/with, a new "confirmed bug" was something you talk about with someone first thing in the morning. |
@refack Right, and by that analogy we don’t have a regression label because nobody here has beepers for Node core (I think). 😄 Also, I don’t think there’s much point in explicitly prioritizing beyond |
Obv 😄. |
@refack if a bug troubles someone enough, it will be fixed regardless of it being a new one or a regression. If no one volunteers for it, it may be open indefinitely, again, regardless of the nature of the bug. That's how open source works ¯\_(ツ)_/¯ |
Looks useful to me. I'll close but @refack, you might want to post a PSA on nodejs/node if you want collaborators to start using it - not that many people watch nodejs/CTC. |
Yeah I thought about closing. Though the secondary point what to document its significance. One more point, a new bug can stay orphan, but for resgressions there's an easy solution: reversion. |
Sounds reasonable. |
I'm suggesting adding a
regression
tag to issues/PRs innodejs/node
.Aside from just differentiating those issues, I think they should get higher priority as well.
This tag should cover
master
breakages i.e. "Regression Tests" failures :-DThe text was updated successfully, but these errors were encountered: