Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Proposal to improve Target Milestone handling


"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


Back to the top