search

barosl / homu

A bot that integrates with GitHub and your favorite continuous integration service
http://homu.io/
MIT License
661 stars 102 forks source link

feature request: ignore "fix #NNNN" notes when the referenced issue is tagged as a regression #159

Open pnkfelix opened 6 years ago

pnkfelix commented 6 years ago

I don't know if this request belongs here and/or should be generalized in some way to apply to projects other than rust-lang/rust ... but here goes:

A recent bug made me realize that a pretty common process failure we encounter in Rust is the following:

  1. Bug with issue number #NNNN is discovered to affect either the stable or beta channel of Rust.
  2. Bug is tagged as a corresponding regression, and often given high priority.
  3. A fix is developed and a PR posted, against the master branch of the repo, that says Fix #NNNN. The PR is reviewed, accepted.
  4. Bors lands the fix on master, and closes the issue. But the work isn't done, because we still need a beta backport.

I believe that so far, we've been relying on people to either 1. not tag PR's that are fixing such regressions with Fix #NNNN, or 2. re-open the regression issue after the PR lands. But muscle memory is hard.

I think it would be better to make bors itself not close the issue when its tagged as a stable/beta regression if the fix is being merged into the master branch. Instead we should require more human intervention to evaluate whether the issue is truly resolved and should be closed.

(As a special case, we might allow bors to still close such issues when the corresponding PR is actually going into the right branch, i.e. stable or beta. But it wouldn't be the end of the world if that special case did not get implemented, IMO.)

pnkfelix commented 6 years ago

It was pointed out to me that github is the one closing the issues; I misinterpreted the message "bors closed this in #54199 on Sep 26" on the web interface as describing a direct action of bors, but its just a side-effect of bors landing a commit.

It was also suggested that we could still perhaps have bors deal with this for us, by e.g. having bors automatically reopen such issues after github closes them...