First off, this is a 2.0 feature, no doubt about that.
I like this thread because I think that tool integration is a very
important issue for software engineering environments. The issue is
usally called "software process integration" and several attempts have
been made to make this the central issue in building these kinds of
tool sets (called PCSEE's, process-centered software engineering
environments). Based on my experiences, I feel that we should address
this, but that simple surface-level integration is preferable to deep
integration.
I absolutely agree with the observation that an issue report has a
given status relative to a given version of the source code. In fact,
I have heard this from some potential collab.net customers too. The
way to support this is probably to keep a list of version-status pairs
for each issue report. This could be displayed in the UI as the
status for the latest version reported, with a link to a page with a
table of status in each version.
I also absolutely agree that the single process event of checking in
code should be used to update as many of the development artifacts as
possible (but not more). And, mentioning the issue ID number in a
commit message is probably a good way to indicate that that check-in
relates to that bug.
Some bug tracking systems provide for a bug life-cycle, a state
machine that shows all possible statuses and all legal transitions
between them. That has the nice features that you can define that
part of the software development process and maybe even attach scripts
to the transitions. I would not want to see scarab go too far down
the road of formalizing the bug life-cycle. For now, lets make as few
assumptions as we can.
Here is a usage scenario for how I suggest we achieve shallow
integration:
1. A developer reads the bugs that are assigned to him, maybe keeping
them open in a browser while he/she codes.
2. The developer makes a change to the code, hoping to fix the
problem. The coding session may actually touch many files and affect
many open issues.
3. The developer tests the code and is satisfied that it is fixed.
4. The developer checks in the code, and inserts the issue ID numbers
into the log message. The syntax could be
ISSUE_ID ('{' (KEY '=' VALUE)+ '}')?
Where KEY is one of the fields of a bug report. Mentioning just the
issue_id would default to {status=code-checked-in}
5. CVS/Subversion does the commit and mails a commit email messge to a
mailing list, e.g., cvs@argouml.tigris.org.
6. Scarab is subscribed to this list and parse out any issue ID
numbers in the log message section of the email.
7. Scarab adds a version-status record to each mentioned issue. Also,
scarab adds the log message to the coments for each affected issue
report, or adds a link to the archived email message.
The fact that the status is "code checked in" means only that, not
that the bug is resolved or fixed. I can imagine that we might have
a nightly test suite runner that works in much the same way: running
its tests, sending out a notification email with descriptions of the
tests that were run (which might include an issue number for
regression tests, and {status=regression-test-passed}.
We have been wanting some kind of remote email interface to scarab
where developers can accomplish simple updates by replying to email
sent from the system or cc'ing scarab on messages sent to the dev
mailing list. E.g., when a project leader sends an email to the dev
mailing list, he/she might also include some commands to raise the
priority of a given issue. I think that the integration between
scarab and other hosted tools can be achieved via the same interface,
at very little added cost.
>From: "Jonathan S. Shapiro" <shap@eros-os.org>
>> A bug is not fixed when code is checked in. A bug is fixed when a test
>case
>> or test cases demonstrating the bug run correctly.
>>
>> You definitely *do not* want tracking of which bugs are fixed to be
>> automatic. When you merge a good branch with something else, bugs may
>> regress. The only way to know is to run tests.
>
>Humm... to me this is a half-truss. While I agree that a bug is not "fixed"
>when code is checked-in, the code check-in is part of the life of the bug:
>it indicates that now this particular bug should be restested (actually you
>could call the check-in a "fix" while the important event for a bug is
>"close"). As such it makes sense to track both with the same tool: you
>check-in some code becose of such and such PR, it would be nice to see these
>PRs state updated accordingly (which does not mean that they are closed).
>
>The goal here is to automate the process where it makes sense. However I
>think that this is more like a secondary issue at this time. Maybe a version
>2 item ?
>
>Patrick.
>
jason!
--
Jason Robbins, Ph.D. Collab.Net is hiring open source developers!
Chief Architect http://www.collab.net/jobs
Received on Sat Oct 21 14:36:05 2006