[PATCH] D53691: Introduce bug life cycle documentation.

Thu Oct 25 13:43:14 PDT 2018

rnk added inline comments.

================
Comment at: docs/BugLifeCycle.rst:103-104
+* There is a sound reason for not fixing it (WONTFIX).
+* There is a specific and plausible reason to think that a given bug is
+  otherwise inapplicable or obsolete.
+
----------------
rnk wrote:
> What about this scenario:
> - User reports bug with vague reproduction instructions
> - Bug languishes for one year
> - Developer does a pass over open bugs, tries to reproduce, but is unable to because there never was a clear, confirmed repro in the older version of llvm.
> 
> I think our policy should encourage us to close such bugs with some sort of "stale / instructions unclear / needsinfo" status along with a request for more information. The point is to put the bug into a state that says that no further action will be taken by LLVM developers unless the original reporter does something. For old bugs, chances are they won't.
> 
> I think as long as we encourage reporters to reopen if they have more info and can still reproduce the bug, this won't be discouraging to reporters. If the bug languished for a year, it's best to acknowledge that nothing happened and nothing is likely to happen without more information.
> 
> I believe this would be a better policy than asking developers to ping stale bugs for more info from the OP while leaving the bug open. That just leaves the bug open and means it will come up during the next bug scrub, requiring more developer time to close it out if there was no response.
> 
> Looking at our current resolution statuses, I guess I'd close bugs that we were never able to confirm were bugs with "WORKSFORME".
My previous comment is my opinion, and I don't think it reflects the consensus of the last llvm-dev discussion we had about this, so don't let it block the document, which I think is important. We can keep discussing policy after we have a doc.

Repository:
  rL LLVM

https://reviews.llvm.org/D53691