Re: Setting up the issue tracker

Christopher Lenz wrote:
> Hi folks,
>
> we need to configure the SF issue tracker for our needs. Basically
> there are two option lists to populate: "categories" and "groups" (so
> much for meaningful names).
>
> For categories, I think we should add the components outlined in the
> project charter and then some:
>
>    - WDTE Core
>    - WDTE UI
>    - WDTE XML Core
>    - WDTE XML UI
>    - WDTE CSS Core
>    - WDTE CSS UI
>    - WDTE JavaScript Core
>    - WDTE JavaScript UI
>    - Infrastructure (Web site, mailing lists, CVS, etc)
>
> Note that I've added the WDTE prefix to the category names here because
> it would make it easier to add sub-projects like JSP tooling later on.

I think this sounds fine and makes things quite clear.  The only possible
concern would be if users were unable to determine where an Issue belonged
in Core vs. UI.  If you know the where the problem is in the code it is easy
to assign it, otherwise it is much more difficult.  Is there an important
reason to seperate the Core and UI in the categories?

> Populating the "groups" option list is less obvious. SourceForge
> suggests "Add groups like 'v1.2', 'unsupported', 'unverified', etc.".
> Obviously groups are issue-tracker-global, so we can't use them to
> further identify modules inside components ("categories"). I think
> pretty much the only thing that makes sense here is version numbers,
> considering that we probably want unified releases including all
> components, and thus the same version numbers across components.
>
> But version numbers is not the same as version numbers :-P. They might
> refer to the version in which the submitter discovered the defect, or
> they might refer to target versions where we intend to have the issue
> fixed/implemented. I think I prefer target versions, but I'm not sure.
> Having the number of the version used by the submitter is very useful,
> but target versions are nice for release management. Any preferences?

I agree that target version would be the preferred choice here.  I think
that the version a problem is found in (along with other relevant info like
OS, Windowing system, etc.) are an essential part of the problem text but
having it in the group field doesn't provide a great deal of benefit.

> Cheers,
> Chris
>
> PS: Why is this list so quiet? There was more discussion going on when
> we were abusing the web tools newsgroup than here where we can safely
> discuss everything without being off-topic. I think the number of
> subscribers is currently higher than the number of (non-test) messages
> posted to this list, so at least there are a bunch of people listening
> ;-)

Sorry I haven't been commenting more... I believe that at this stage, making
decisions and moving forward is essential to gaining the momentum we need to
be successful.  I have been largely in agreement with the majority of what
you have been doing Chris and in fact have been very pleased with the
leadership you have provided on this.  I don't believe that it makes sense
to hold up the entire process to squabble over a minor detail.  With open
and reasonable communications we can work out the details of minor issues as
they become important.

But I'll be sure to add more 'I second the motion' messages in the future...
:-)

Matt Brozowski




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn