Re: Setting up the issue tracker

Am 02.02.2004 um 17:12 schrieb Mathew Brozowski:
> Christopher Lenz wrote:
>> 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)
>
> 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?

The one advantage is that the categories would map one-to-one to 
plugins. But you're probably right that this granularity would cause 
more harm than good, because the users will usually not "get" the 
difference.

>> 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.

Agreed.

>> 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.

Okay, cool. Though I'd prefer the term 'initiative' over 
'leadership'... I really don't want it to look like leadership, and I 
haven't yet done a single thing without asking for objections or 
comments first. :-P

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de



-------------------------------------------------------
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