On 16 December 2013 23:56, Thierry Carrez <thie...@openstack.org> wrote:
> Robert Collins wrote:
>> https://wiki.openstack.org/wiki/BugTriage is a 10 step process: thats
>> not something we can sensible do over coffee in the morning.
>
> Totally agree with that. The idea of those 10 steps was not meant as
> something you could ever complete, it was more a way to state there is
> no point in doing step 8 unless step 1 is covered.
>
> I agree that splitting the process into separate daily / cycle-y
> processes (as you propose below) is a better way to ever get it done.
Ok, cool.
> I like the first and third parts. Not really convinced with the second
> part, though. You'll have a lot of "Confirmed" bugs without proposed
> approach (like 99% of them) so asking core to read them all and scan
> them for a proposed approach sounds like a waste of time. There seems to
So, I'm trying to reconcile:
- the goal of moving bugs into 'triaged'
- which really is:
- keeping a pipeline of low hanging fruit as an onramp
- apparently some documentation needs too, though I'd rather push
/all/ those into DocImpact tags on changes, + those bugs that are
solely documentation issues.
- the goal of identifying critical bugs rapidly
- the goal of steering bugs to the right subteam (e.g. vendor interests)
> be more value in asserting that "there is a proposed approach in the
> bug", rather than "there is a core-approved approach in this bug".
The definition of Triaged on the Bugs wiki page is 'Triaged The bug
comments contain a full analysis on how to properly fix the issue '
Fundamentally for a process to work at scale we can't depend on 'all
triagers naturally figure out which bugs need to be Triaged and which
only need to be Confirmed'. *regardless* of definition of triaged, we
need a system where we don't exhaust people every few weeks reviewing
*every open bug* to figure out which ones have been missed.
I'm *entirely* happy with saying that anyone with the experience to do
it can move things up to Triaged - I see no problem there, but there
is a huge problem if we have any step in the process's inner loop that
requires O(bugs) tasks.
> Furthermore, I'm not convinced we really need to spend core time
> "assessing the proposed approach". You can spend core time on suggesting
> a proposed approach (i.e. turning Confirmed into Triaged), though.
So if I rephrased
Daily tasks - second layer - -core current and previous members
1. Review Confirmed+High[1] bugs
1.1. If there is a full analysis on how to properly fix the issue move
to Triaged
1.2 If not, add one.
2. If appropriate add low-hanging-fruit tag
You'd be happy? The reason I didn't write it like that is that this
burns *more* core time. I was trying to propose a process where we can
scale a competent but non-core team up without demanding that -core
commit to boiling the ocean.
The different between the phrasing I had and the one you seem to be
proposing is that rather than promoting and guiding on bugs, -core are
being asked to /do/ on every bug. That places a lot of load on -core,
*or* it means we get many less bugs triaged.
If we say that anyone with reasonable competency can do it, we could say:
Daily tasks - second layer - more experienced folk
1. Review Confirmed+High[1] bugs
1.1. If there is a full analysis on how to properly fix the issue move
to Triaged
1.2 If not, add one.
2. If appropriate add low-hanging-fruit tag
> You basically have the following states for a bug:
>
> A - Brand new
> B - WAT (incomplete, ask the reporter for more info)
> C - I don't have the expertise to judge (but I can add tag)
> D - Yes this is definitely a bug, here is its priority
> E - This is a bug and here is a suggested approach to fix it
> F - I'm core and I bless that way to fix it
> G - I started working on that fix
> H - The fix is in code review
> I - The fix landed in master
> J - The fix landed in a milestone
> K - The fix landed in a release
>
> That is way too many states, especially if you rely on humans to set
> them. My experience is that humans deal with 3 bug states correctly, but
> start to fail doing it consistently if you ask them to set 4 or more.
I would quibble about that list - for instance tagging and expertise
to judge project impact tag properly are IME the same.
There are many dimensions of input to bugs, and what you're calling
states there are really the combination of things from different
dimensions. Timeline interactions for instance, don't change the state
of a bug, but they change whether we want it to show up in bug
searches.
> In the current setup (constrained by what Launchpad supports) we use
> tags for C, we ignore F, we combine G+H, and we combine J+K:
>
> A - New
> B - Incomplete
> C - (New + tagged)
> D - Confirmed
> E - Triaged
> F - (Triaged + comment)
> G - In progress
> H - In progress (automatically set)
> I - Fix committed (automatically set)
> J - Fix released (automatically set)
> K - (Fix Released + remilestoning) (automatically set)
>
> I think less states (and more consistency) is better than plenty of
> states that nobody sets correctly, so you can't rely on them. If you
> take "In progress" for example, it's a mess: people don't set it when
> they start working on it, or don't unset it if they stop, there is no
> consistency enforced with "assignee", and it prevents you from using it
> purely to mean there is a code review in progress. We end up having to
> spend triaging time fixing it. Better use the assignee as a way to
> assert you should work on something, and then have a "In review" state
> automatically set.
I agree - automation and simple assessments are really good.
> In a ideal system I'd personally not track F, J and K. Not totally
> convinced there is value in trying to track E and G since it relies on
> devs setting it (and they usually don't). So that would give:
>
> A - New
> B - Incomplete
> C - (New + tagged)
> D - Prioritized
> E/F - (Prioritized + comment)
> G - (Prioritized + assigned)
> H - In review (automatically set)
> I - Fix merged (automatically set)
> J/K - (Fix merged + branch set)
>
> 3 human-set states, topic tags, and 2 states set by Gerrit links. Yes
> it's simplistic, but I think that would not work better (less detail but
> more accuracy).
To me this is exactly what I was getting at when I asked about the
definition of triaged. :). The difference between 'confirmed' and
'triaged' in this ideal system is nil, since it's priority-set +
comments.
And thats what I'd really like to do :) We ran that for LP itself, and
while there was some bikeshedding, as a process and a way to make sure
the things that folk need to work on were really visible, it worked
fantastically.
-Rob
--
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
