Repository navigation
PSA: new tag "regression" #12493
Description
Activity
Please also label these with
confirmed-bugor they will not be seen.Yeah I'm not sure it makes sense to label something as a 'regression' without 'confirmed-bug' or some other 'confirmed' status.
I'm not objecting, but since only Contributors can tag, I tought "regression" means confirmed regression.
@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.Reacted by Refael Ackermann@refack ... I think the issue is more than the existing confirmed-bug label is something many of us already actively watch for. If things are marked regression without also being marked confirmed-bug (which such things are) then the likelihood of those being missed rises significantly.
Gotcha! 👍
Added "confirmed-bug" to first comment.
Is meaning of regression documented somewhere? How is it different from a confirmed-bug?
Is meaning of regression documented somewhere? How is it different from a confirmed-bug?
👍
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 existAs 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 onmastergoes red)"confirmed-bug" could stay orphan forever (as is in OSS). While a "regression" even if not solved could always be reverted.
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)Another idea: we can use the regression tag to mark PRs that cause regressions and should not land alone(instead it should land together with another fix)
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 fixregressionbugs, and should be fast-tracked
-maybe as a post-mortem marking of PRs that causedregression
I don’t think this needs to remain open at this point, feel free to re-open if I’m wrong.
Reacted by Refael Ackermann
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
masterturns 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.