Andrew McIntyre wrote:
On 8/14/07, Rick Hillegas <[EMAIL PROTECTED]> wrote:
1) The Affects Versions field? Seems like the wrong choice for that
field. I would expect to see a released version in that field. 10.3.1.5
is a moving target.
And also can contain changes that may not be in 10.3.1.4 that have
problems, which means that 10.3.1.5 would be the appropriate choice.
I think this is a rare case. However, when it occurs, the person logging
the bug needs to tell the community the subversion timestamp of the
snapshot which has the bug. In this rare case, we should create a new
version id which contains the subversion timestamp, something like
"10.3.1.5 (svn 654321)". The usage you are describing suggests to me
that people are generating snapshots/patches outside the community,
logging issues against those snapshots, but not giving the community
enough information to participate in the solution.
It could refer to any of a number of points in
subversion time on the 10.3 branch. That makes it inappropriate for this
field. The person reproducing the bug will want to work with a well
defined version, not a moving target.
In the long view it does, in fact, refer to a very specific range of
subversion changes: from the checkin where the version was bumped to
the checkin where the version is bumped again (minus one rev). Since
we can't put the Subversion revision where it was reproduced in this
field, having the version where it was discovered is the obvious next
best choice since it refers to a specific range of subversion
revisions. As for the person fixing it, I would imagine that they
would always be working at the head of the trunk or branch, if they're
trying to fix it.
The issue is not just of concern to the person fixing the bug. For the
sake of the larger community, "head of the branch" is a moving target
with limited value.
2) The Fix Versions field? Seems like an even worse choice for that
field. There will never be a 10.3.1.5 release. If there is a new release
on the 10.3 branch, it will be called something like 10.3.2.x.
Yes, but what if there is never a release on the 10.3 branch again?
I'm afraid I'm lost here. It seems that this objection applies whether
we call the "limit point" of the branch 10.3.2.0 or 10.3.1.5.
Then that id is the most appropriate, and that's where all of our old
branches are at the moment at their head, on their last release
version + 0.0.0.1. Also, I feel both the release id and current
version are useful for release planning, the former says 'i'm planning
on getting this done by the time the release is out' and the latter
says 'i'm working on this right now.'
Perhaps the disconnect arises from the different patch usage patterns at
IBM and Sun. It seems to me that IBM tends to not bump the patch id when
generating a patch, but Sun does. Sun's usage implies that, on the eve
of building 10.3.2.0, the head of the 10.3 branch might actually be
tagged as 10.3.1.9.
Regards,
-Rick
andrew
