[PATCH] D53691: Introduce bug life cycle documentation.

Kristof Beyls via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 29 08:18:14 PDT 2018


kristof.beyls added inline comments.


================
Comment at: docs/BugLifeCycle.rst:46-47
+Make sure that you have one or more people on cc on the bug report that you
+think will react to it. We aim to automatically add specific people on cc for
+most products/components, but may not always succeed in doing so.
+
----------------
jhenderson wrote:
> Maybe this should contain instructions on how to identify a good person to add as a CC? I imagine a good basis is the same as the people you'd add as reviewers for a change in the area.
I think we should aim to have at least one and ideally a few people by default added on CC for each component, as I expect that users that are not developers may find it hard to follow the guidelines we use for finding code reviewers (look at CODE_OWNERs; use svn/git blame on the code area affected).
Nonetheless, it may indeed be useful to say something along the lines of "If you know the area of LLVM code the root cause of the bug is in, good candidates to add as cc on the bug report may be the same people you'd ask for code review on that area. See Phabricator.html#requesting-a-review-via-the-web-interface for more details."


================
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:
----------------
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.


Repository:
  rL LLVM

https://reviews.llvm.org/D53691





More information about the llvm-commits mailing list