Re: [wtp-dev] Proposal to improve Target Milestone handling

[Amy Wu <amywu@xxxxxxxxxx>]

"Note
that using comments or whiteboard to mark release commitments is not a
good solution as neither is easily queryable or visible in bug lists."

Actually, you are able to query and
display the status whiteboard.
To query, in the "Advanced Search"
tab, at the bottom, "Advanced Searching Using Boolean Charts"
you can select "Status Whiteboard" as one of the fields you can
query.

To display, click on the "Change
Columns" link at the bottom of your Bug List and check the checkbox
for "Whiteboard"

So I believe whiteboard is still an
option, unless your emphasis was on "easily."  Since you
can write anything in the whiteboard, I guess it could be hard to figure
out exact keywords to use.

______________________________
Amy Wu
Structured Source Editor
919.254.0299, T/L 444.0299
amywu@xxxxxxxxxx

"Konstantin Komissarchik" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

05/18/2006 08:18 PM

Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>

To	"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject	[wtp-dev] Proposal to improve Target Milestone handling

Problem
 
We currently have no way of designating commitment
to fix a bug in a certain release vs a specific milestone in that release.
In my personal experience and judging by how other people handle their
bugs, one needs to be able to designate a bug as one that will be fixed
in a certain release (such as 1.5 or 2.0) before one knows precisely which
milestone the bug will be fixed in. Lack of this facility has led developers
across wtp to adopt one of two behaviors: (1) set the target milestone
immediately to the current milestone and then roll the bug from milestone
to milestone, or (2) set the target milestone immediately to the last milestone
in the release even if the bug might be fixed prior to that milestone.
The problem with both of these approaches is that they dilute the meaning
of this field. It is no longer possible to distinguish genuine milestone
targets from these fuzzy ones.
 
Proposed Solution
 
We could add an entry for each release into
the list of items available in the Target Milestone field (such as 2.0
in addition to 2.0 M1, 2.0 M2, etc.). This way devs could target bugs to
a particular release before they know which milestone the bug will be fixed
in. Once a particular milestone can be committed to, the Target Milestone
settings can be adjusted accordingly. This approach, I believe, would take
care of the situations that prompt the developers to utilize workarounds
described above while being true in spirit to the intention behind the
Target Milestone field.
 
Note that using comments or whiteboard to
mark release commitments is not a good solution as neither is easily queryable
or visible in bug lists.
 
- Konstantin

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev