(Originally sent to a smaller set of folks; expanding to laszlo-dev.)
On May 2, 2007, at 10:37 AM, P T Withington wrote:
I like this.
One thing that has also bothered me about Fix Version is that when
I migrated changes there was no way that I could extend the 'Fixed
in Change#' field to give the change# for the migrated fix.
Ideally, for a bug you want to record the the branch and revision
for each time it is migrated.
Without that, 'fix version' is ambiguous, because we use it both as
a goal (this should be fixed in verison foo) and as an
accomplishment (this has been fixed in version foo). The change#
disambiguates that, but not for branches.
I agree completely. There's another problem, which is that before an
issue is resolved, Fix Version is a directive to the developer, but
after the issue is resolved, Fix Version describes where the change
was added.
Really we want to shift the workflow around to be more about
branches. We should have:
1. Affects Version(s) -- actual released versions, if any, where this
bug was found.
2. Repro Source(s) -- source branches (with revision!) where the bug
was reproduced. Bugs found in nightlies would be reported using this
field
3. Fix Source(s) -- source branches (with revision!) where a fix was
integrated
4. Fix Version(s) -- actual releases where the fix was made available
#1 and #2 track the origination of the issue, if any (they would be
blank for tasks and improvements, for example). #3 is set by the
developer and by the release managers as the change is integrated
across the various active source trees. And #4 would only be set by
the release manager as part of the final release checklist.
JIRA could be made to do most of this, with the exception of the
branch/revision tracking. I suppose the branch is implicit in the
revision #, since the details of the revision would be specific to a
particular branch. But that wouldn't be very readable.
jim
On 2007-05-02, at 13:18 EDT, Jim Grandy wrote:
It's been bothering me for a while that we have been placing bugs
in the 4.0.1 Fix Version *before* we decide whether to actually
migrate their fixes to branches/4.0. So I just did a little
something about it, by bringing back the "Legals" Fix Version.
This Fix Version is intended for changes destined for branches/
legals -- so it is where general, non-version-specific changes
should go. Once a change is accepted for integration to branches/
4.0 and checked in there, then its Fix Version should be updated
to include "Profiterole (4.0.1)" as well.
So:
- set Fix Version of "Legals" for bugs that are 4.0.0 regressions,
or work scheduled for branches/4.0
- Once a fix is accepted for integration to branches/4.0, and has
been checked in, update the bug to *also* include a Fix Version of
"Profiterole (4.0.1)". (Cmd-click on the mac will extend the
selection.)
One remaining item to do, though: someone needs to go through the
bugs that have been resolved so far against Profiterole (and which
are now all just against Legals), determine which ones were in
fact migrated to branches/4.0, and set the Fix Version field
accordingly. Unfortunately, it doesn't look like the integration
checkins included the bug numbers, so the correlation will have to
be done manually. Max, as release manager for branches/4.0 I'm
going to ask you to do this. It'll also serve as an inspiration to
include bug numbers in integration checkins from now on :-)
jim
