[PATCH] D53691: Introduce bug life cycle documentation.

[Kristof Beyls via Phabricator via llvm-commits]

kristof.beyls marked 13 inline comments as done.
kristof.beyls added inline comments.


================
Comment at: docs/BugLifeCycle.rst:96
+Closing bugs is good! Make sure to properly record the reason for closing.
+
+Examples of reasons for closing are:
----------------
kristof.beyls wrote:
> jhenderson wrote:
> > kristof.beyls wrote:
> > > RKSimon wrote:
> > > > Do we need to distinguish between resolving and closing a bug? We have verified/closed states but AFAICT these are barely used.
> > > Good point.
> > > As far as I can see, we don't really attach much difference in meaning to the "RESOLVED", "VERIFIED" and "CLOSED" states.
> > > Therefore, my opinion right now is that we're probably best of to just remove the "RESOLVED" and "VERIFIED" states from our bugzilla instance and only keep the "CLOSED" state, making the workflows simpler.
> > > I do think that this change can be made mostly orthogonally to completing this documentation. If/When we remove the "VERIFIED" and "RESOLVED" states, the documentation becomes less open for interpretation.
> > > What do others think about this?
> > This is purely a personal opinion, but I would prefer to keep RESOLVED, above VERIFIED or CLOSED, partly because that's how I'm used to using bugzilla (I've always used RESOLVED). However, if consensus is against me on this, I don't mind. If we went down this route, you should probably change "closing" to "resolving" here and elsewhere.
> I have no strong preference myself on RESOLVED vs CLOSED.
> Having looked at the Bugzilla documentation for a few minutes just now on how to remove possible values for field "status", it seems that the "RESOLVED" value cannot be deleted, whereas "CLOSED" and "VERIFIED" can be deleted. Therefore, I think there is a strong technical argument to just decide that "RESOLVED" is the final bug status we retain, if we decide to only have 1, not 3 final bug statuses.
I have now updated the proposed documentation here as if we've decided to remove the VERIFIED and CLOSED states.
After looking into what it'd take to do so, it seems pretty straightforward for a bugzilla admin to remove the VERIFIED and CLOSED states.


================
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.
+
----------------
kristof.beyls wrote:
> rnk wrote:
> > 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.
> Looking back at the last llvm-dev discussion, my impression is actually that most people were in favour of something along the lines of what you're proposing. Let me have a stab at concisely writing something up that hopefully encodes consensus.
I've made an attempt at concisely writing up something the conveys the intent of what I believe the consensus is.


https://reviews.llvm.org/D53691