To follow up on status mtg discussion of
this
I like Konstantin’s suggestion of
adding release level ids to the “Target” field because it gives a consistent
intermediary between “Assigned” (which I think means confirmed as a
legitimate bug or enhancement request and in the hands of the appropriate
committer) and “will be fixed in this specific milestone”.
Note that this proposal does not suggest
that all “confirmed” bugs should be targeted for the next/current
release, nor does it suggest that targeting to a release provides the same level
of guarantee to the reporter as targeting to a milestone. It only
provides something incrementally better than Assigned.
I see it as an alternative to a list of
bug numbers in a release “plan” document, without compromising the
integrity of milestone targeting.
Thanks, Ted
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of John Lanuti
Sent: Monday, May 22, 2006 12:08
PM
To: General
discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Proposal to
improve Target Milestone handling
One thing I haven't seen is the ability to change the
whiteboard setting for more than one bug at a time. Is this possible?
Thanks,
John Lanuti
Software Engineer, IBM Rational
jlanuti@xxxxxxxxxx
t/l 441-7861
"I know this lady way down in my country.
She is so pretty that my eyes throw disguises at me.
Now we will sit and we'll wonder about our future,
But now I'm thinking that today sounds fine to me." - Of A
Revolution
Amy Wu/Raleigh/IBM@IBMUS
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
05/22/2006 02:02 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
|
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_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev