<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:kristof.beyls@arm.com" title="Kristof Beyls <kristof.beyls@arm.com>"> <span class="fn">Kristof Beyls</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - test how the "NEW"/"UNCONFIRMED"/"CONFIRMED" states work in our bugzilla"
href="https://bugs.llvm.org/show_bug.cgi?id=39482">bug 39482</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Summary</td>
<td>test
</td>
<td>test how the "NEW"/"UNCONFIRMED"/"CONFIRMED" states work in our bugzilla
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - test how the "NEW"/"UNCONFIRMED"/"CONFIRMED" states work in our bugzilla"
href="https://bugs.llvm.org/show_bug.cgi?id=39482#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - test how the "NEW"/"UNCONFIRMED"/"CONFIRMED" states work in our bugzilla"
href="https://bugs.llvm.org/show_bug.cgi?id=39482">bug 39482</a>
from <span class="vcard"><a class="email" href="mailto:kristof.beyls@arm.com" title="Kristof Beyls <kristof.beyls@arm.com>"> <span class="fn">Kristof Beyls</span></a>
</span></b>
<pre>I was testing how the "NEW"/"UNCONFIRMED"/"CONFIRMED" states work in our
bugzilla when enabling the builtin "product uses CONFIRMED/UNCONFIRMED" feature
in bugzilla.
The result was that I concluded it wasn't very usable for us.
Let me repeat here what I said on a related LLVM-dev mail thread on this:
"""
It seems that bugzilla by-default will put bugs in the “CONFIRMED” state when
creating new bugs, if the reporter has “can-confirm” rights. I believe our de
facto policy is for everyone with an account to be able to confirm bugs. Also,
you need an account to be able to report a bug. The result is that all new bugs
by default will go to status “CONFIRMED”, unless the reporter carefully
remembers to change the default and select “UNCONFIRMED”. (Also see
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=915682">https://bugzilla.mozilla.org/show_bug.cgi?id=915682</a> which suggests this
behaviour is not configurable).
Unless that can be solved, I fear that many bugs will be reported with the
default “CONFIRMED” status even though they aren’t triaged yet. I believe that
is worse than the current default “NEW” state.
The only work around for this behaviour where we still get a “to be triaged”
state I can think of at the moment is to introduce a custom “CONFIRMED” status,
not using bugzilla’s built-in special “UNCONFIRMED” support and have a flow
that would allow something like:
NEW -> CONFIRMED -> ASSIGNED -> RESOLVED -> …
The advantage is we’d have separate states to represent “this bug was raised”
(NEW) vs “this bug was triaged & confirmed” (CONFIRMED).
The disadvantage is that we’ll start deviating from the default bugzilla
workflows.
"""
Since then, we've indeed implemented a custom CONFIRMED state, not using
bugzilla's limited built-in support for it.
Conclusion: this test bug can be resolved.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>