Repository navigation
PSA: new tag "regression" #12493
Description
There is a new tag for issues (available also for PRs) called "regression" please use it in addition to "confirmed-bug" to indicate that something that used to work has stopped working, or in the case that CI for master turns red.
IMHO we all should be more attentive to this list:
https://github.com/nodejs/node/issues?q=is%3Aopen+is%3Aissue+label%3Aregression
Looking for advice as to how to document this in the guides
I believe this should be reflected in one of the guides, I'm not sure which and exactly how. I'm seeking your advice.
some personal opinions
For me personally an ignored red CI is perceived as an act of disrespect to your fellow devs, and I find that offensive.
-
These issues may arise from a user report, where I believe acknowledging that this is indeed a regression will help communicate that we are taking this seriously. IMHO even a lively discussion helps the reporter feel that they are being heard (e.g. v7.x undocumented backward incompatibility of url.format() #11103)
-
Since the CI turning red for
masteris a situation that frustrates other contributors, and may lead to waste of others time, I posit that the respectful thing is for "landers" to run a post land CI job and in cases that CI turns red, open a "regression" issue, so that they can recruit help solving the issue ASAP. In cases where a solution seems to be far, I recommend reverting, and reopening the PR for improvement.
Activity
Fishrock123 commentedon Apr 18, 2017
Please also label these with
confirmed-bugor they will not be seen.mscdex commentedon Apr 18, 2017
Yeah I'm not sure it makes sense to label something as a 'regression' without 'confirmed-bug' or some other 'confirmed' status.
refack commentedon Apr 18, 2017
I'm not objecting, but since only Contributors can tag, I tought "regression" means confirmed regression.
jasnell commentedon Apr 18, 2017
@refack ... I think the issue is more than the existing
confirmed-buglabel is something many of us already actively watch for. If things are markedregressionwithout also being markedconfirmed-bug(which such things are) then the likelihood of those being missed rises significantly.refack commentedon Apr 18, 2017
Gotcha! 👍
refack commentedon Apr 18, 2017
Added "confirmed-bug" to first comment.
sam-github commentedon Apr 19, 2017
Is meaning of regression documented somewhere? How is it different from a confirmed-bug?
refack commentedon Apr 19, 2017
👍
I'm looking for suggestions as to where and how to document this.
P.S. "confirmed-bug" is very sparsly documented:
confirmed-bug - Bugs you have verified existrefack commentedon Apr 19, 2017
As I wrote in nodejs/CTC#106. "confirmed-bug" could have been there for ever, and just been discovered.
"regression" means something that used to work stopped working (my hated example, CI on
mastergoes red)"confirmed-bug" could stay orphan forever (as is in OSS). While a "regression" even if not solved could always be reverted.
joyeecheung commentedon Apr 24, 2017
Another idea: we can use the
regressiontag to mark PRs that cause regressions and should not land alone(instead it should land together with another fix)refack commentedon Apr 24, 2017
Sounds good, since I can't think of a really good use for
regressionon PRs.Ideas I thought about, but am ambivalent about
-maybe PRs that fix
regressionbugs, and should be fast-tracked-maybe as a post-mortem marking of PRs that caused
regressionaddaleax commentedon May 26, 2017
I don’t think this needs to remain open at this point, feel free to re-open if I’m wrong.