Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

add tag: regression #106

Closed
refack opened this issue Apr 17, 2017 · 9 comments
Closed

add tag: regression #106

refack opened this issue Apr 17, 2017 · 9 comments

Comments

@refack
Copy link

refack commented Apr 17, 2017

I'm suggesting adding a regression tag to issues/PRs in nodejs/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 :-D

@Fishrock123
Copy link

Isn't that pretty much also covered by confirmed-bug?

@refack
Copy link
Author

refack commented Apr 18, 2017

I think confirmed-bug are newly discovered bugs, where probably the solution should come with a new regression test-case.
IMHO "Regression"s are worse, because "confirmed-bug"s could have been hidden there forever, while regression mean someone (or CI) discovered that something that used to work stopped working, means that for someone a previously working system became broken.

P.S. From my experience this distinction is commonly used to prioritize issues.

@refack
Copy link
Author

refack commented Apr 18, 2017

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.
A "regression" means a beeper in the middle of the night.

@addaleax
Copy link
Member

@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 confirmed-bug – it won’t usually get an issue fixed any sooner.

@refack
Copy link
Author

refack commented Apr 18, 2017

Obv 😄.
I know there are no direct clients, but there are frustrated devs, that get red on the CI and don't know why.
I'll watch it. Hope others will as well.
https://github.com/nodejs/node/issues?q=is%3Aopen+is%3Aissue+label%3Aregression

@aqrln
Copy link

aqrln commented Apr 18, 2017

@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 ¯\_(ツ)_/¯
That said, I'm not gonna argue that this distinction may make sense, especially given that you've already created the label. I think the issue can be closed?

@bnoordhuis
Copy link
Member

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.

@refack
Copy link
Author

refack commented Apr 18, 2017

Yeah I thought about closing. Though the secondary point what to document its significance.
OSS is obviously good-faith volunteering, but IMHO issue priorities help communicate our attentiveness to the users, respect to the devs' time, and guidance to volunteers.

One more point, a new bug can stay orphan, but for resgressions there's an easy solution: reversion.
( @bnoordhuis stole my "close" )

@aqrln
Copy link

aqrln commented Apr 18, 2017

One more point, a new bug can stay orphan, but for resgressions there's an easy solution: reversion.

Sounds reasonable.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants