Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Release and target fields are now in Bugzilla

I've had the webmaster add some concrete release and target values to our bugzilla
schema. They are named similar to how other projects name theirs ... "1.0" for the release,
"1.0 M3", "1.0 M4", etc. for the targets.  I'd like to suggest the following text be added to
our "practices" document to describe how these fields are to be used. I am
not trying to invent anything new or complicated here .... but just trying to mimic how
I think other projects use the fields. So ... if I've gotten anything wrong, or anyone has
any suggestions for improvements to this description, please post reply to this mailing list for
review and discussion.


= = = = = = = = =
Only when someone is actively assigned to work on a bug and its done or
near certain to be in a particular milestone is it marked with "Mx" target.
That is, the Milestone target not used for long term planning, but short
term picture of the way things are.

If something can not be done for the next milestone, but is still hoped to
be in Release 1, is should just be left unassigned until its actually being
worked on and near certain to be in a particular milestone. This is simply
to avoid implicitly "over promising" anything that someone may misinterpret
as firm commitment.

Any enhancement or bug that is a good idea, but can't be contained by core
teams in next planned release, should be marked as "resolved, later". Bugs
marked this way are still "open game" for any community contributor to help with, if
such an activity can be coordinated.

Any enhancement or bug that is fairly sure will never be done or fixed
should be marked "resolved, won't fix" ... just to be honest about it, and
allow any protests or appeals to be written by original submitter or
community. Usually "won't fix" denotes the suggestion or 'fix' is not
technically possible, or not a good idea, for some reason -- not just that
"there's not enough time or people right now", since "time and people" depends on
whole community, not just one team.

This scheme should allow us to fairly easily query "things fixed since the
last milestone", or, eventually, "since last release".

= = = = = =

Back to the top