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.
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.
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.
Although changing the workflow to add new status values is
interesting, in reality
not sure this could be done as workflow is probably global across all
projects.
Note, marking issues as resolved as soon as committed doesn't mean
that we can't
do what I have been doing so far which is to attach patch to issue
while "In Progress"
and wait for any feedback before finally committing it and marking it
"Resolved". In
reality it is probably only going to be us core developers who might
even comment
at that time, especially since it is us who are raising most of the
issues.
Anyway, I now have to go assign a whole bunch of issues I fixed
before I had proper
JIRA access to me and mark as in progress so I at least partly know
where I am up
to. As you see this list grow, you might see why being able to mark
them as resolved
and closing off 3.2.X issues as well will help clean things up.
Graham
