Graham Dumpleton wrote:
On 04/03/2006, at 4:59 AM, Jim Gallacher wrote:
More in the way of a general observation rather than on these
specific issues, but I wouldn't necessarily mark things as resolved
just on the basis of the fix being committed. For the big changes at
least, I think we should see some testing on a couple of different
platforms. Maybe we could announce development milestones and ask the
community for a round of testing? Issues would be marked as resolved
after each milestone test cycle. That way we are more likely to catch
problems early and hopefully reduce the time it takes for the next
beta cycle. We should do whatever we can to avoid the 7 months it
took to get 3.2 out. (Actually, it was even longer than that, as
Grisha first mentioned a 3.2 release last spring). Ideally trunk
would always be in a stable enough condition that we could do a
release within a month of making a decision.
Jim, have read through the JIRA documentation page you once referred me to
about status values and what they mean and for "Resolved" it states:
http://www.atlassian.com/software/jira/docs/v3.3.2/images/docs/
config/statuses-addstatus.png
A resolution has been taken, and it is awaiting verification by
reporter. From here
issues are either reopened and or closed.
The issue for us is whether one expects a reporter to verify a fix for
an issue before it
has even been committed to the repository. For them it would probably
be a pain to
have to first checkout latest version from repository and then also
apply a patch. If
they do say it is okay, then by rights should verify it again after it
has then been committed
as who is to say the final commit isn't stuffed up somehow.
I think in most cases it is too much to expect the reporter to verify a
fix. To do so assumes that they are closely following mod_python and
their particular issue. That may not be the case, especially if we defer
the fix to a future version. The reporter may not be subscribed to
python-dev and so not be aware that their bug is receiving any
attention. I'm sure we've all reported bugs in other projects but never
followed up. Perhaps the reporter has stopped using mod_python so the
issue no longer matters to them, but it is still a bug that *we* want fixed.
They way I read all the status values is that it would be quite
reasonable once a fix
has been committed to mark it as resolved. If the reporter then
disagrees it can be
reopened. If they agree it is okay, then it should be closed there and
then and not
wait until some milestone. If a problem is later found, then a new
issue can be created
and linked to the original.
As I argue above I don't think we should depend too heavily on feedback
from the original reporter, as I think that is the exception rather than
the rule. We should use our own judgement on setting the status if we
can reproduce the bug. If the bug is specific to a particular platform
to which we don't have access, then a higher level of involvement from
the reporter will be required.
I'm not saying we should ignore feedback from the reporter, just that it
shouldn't be a requirement.
Without moving issues through resolved/closed in a timely fashion, too
me it just
makes it harder to work out where one is up to amongst the large list
of issues.
Agreed.
I still think we should declare milestones for general testing purposes,
but that is really a separate issue from this JIRA housekeeping discussion.
Jim
