[tools-dev] PMC approval sought for modifications to CDT bugzilla

[turnham@xxxxxxxxxx]

Hi,

We are requesting 3 changes to the bugzilla system for the CDT subproject.

REQUEST #1 -> Addition of "2.0" to the Version list.
DETAIL ->  We would like the Version list to contain -> 0.5, 1.0, 2.0
JUSTIFICATION ->   We have recently made a driver available for Eclipse
R2.0.


REQUEST #2 -> Creation of CDT Target Milestones,
DETAIL -> We would like the following target milestones created (with the
following sort order as well):
     1.0 - 20020308
     1.0 - Release
     2.0 - 20020308
     2.0 - 20020408
     2.0 - Release
In addition, it is not clear how the link to "Target Milestone" is working.
Currently it points to "http://dev.eclipse.org/bugs/notargetmilestone.html
", for all project bugs (JDT, PDE, CDT, etc)...If possible we would like to
have our Target Milestones appear on whatever the correct link should be.
JUSTIFICATION -> We are looking into some automation of build
notes\details, and the appropriate target milestones would allow users (and
us) to know when bugs are to appear in Stable Builds.


REQUEST #3 -> Addition of 3  keywords
DETAIL -> We would like the following 3 keywords added to support feature
tracking (if you can come up with better names, or a better way to support
what we are looking for we would glad to hear it...see below)
     todo
     committed
     uncommitted
JUSTIFICATION ->
We are looking to create a definite process for the opening, classification
and tracking of features.  We are thinking that we can achieve some level
of automated feature tracking by querying bugzilla for certain fields or
states of features.  Specifically we would like to be able to categorize
features into the following groups:

- New -> All features that have been created in bugzilla but not looked at
by anybody yet.
- Todo -> All Features that have been "accepted" by the component owners.
Not every feature would show up on this list: the component owner would
have to explicitly accept it for it to appear. "Accepted" in this case
doesn't mean that we're going to implement the feature, just that we agree
that feature could or should be done (essentially this is just an
acknowledgement that we have read the feature ;-).
- Rejected -> A list of Features that either don't make sense or are
duplicates of other features.
- Committed - A list of all Features that we have committed to doing.  This
would again would something that the component owner sets.
- Uncommitted -> A list of all Features that we have looked at, agreed
should be done but have decided not implement.  This list would be useful
for developers outside or our team who are looking for things they could
do.  (There could be an argument made that this list is not sufficiently
different from Todo)

To get this sort of division we could map these concepts respectively to
the resolution states (NEW,  REMINDME, INVALID, LATER, WONTFIX), but Dean
Roberts thinks that bugzilla's rigorous enforcement of work-flow may hinder
the usefulness of this approach.

So if we had the 3 keywords above, the lifetime of a feature would be
something like this:

1.  The feature gets opened in bugzilla (no keywords yet).
2.  The component owner reads the feature and sets the "todo" keyword
(which lets users, and any DHTML know that this feature has been looked
at), or rejects the feature.
3   Then when we have made a decision about what features we will tackle or
not, we remove the "todo" keyword and add the "committed" or "uncommitted"
keyword depending on if we are going to implement it or not.
4.  Once the feature had been completed, it's resolution state would be
changed to FIXED.

This approach seems fairly inelegant (especially considering that the UI
for adding keywords is just an entry-field), so we would love to hear other
ideas.

Thanks...

Jeff Turnham