Trac Ticket Management

[Amar Takhar]

On 2014-11-23 10:28 -0500, Gedare Bloom wrote:
<snip>
> RTEMS (rtems.git) components:
> * One component for each architecture family; for problems that affect
> those archs or their bsps

We have a 'tag cloud' that can be viewed here: https://devel.rtems.org/tags  
both tickets and wiki pages can be marked using tags.

Components themselves should be very general.  'RTEMS', 'Build', 'Testing', 
'BSP', 'CPU' etc.

Also, we can have further fields.  If we're going to do architecture family we 
should have a new field to list this.  The general rule for adding a new field 
for a ticket is it will be something we will add to, but never remove.  We can 
remove an architecture as an option but never remove the arch field.


> * no_arch -- kitchen sink of arch-independent code: maintainers must
> triage these to assign
> * testsuites
> * Build System -- for Autotools and related issues, and later, Waf
> 
> Support components:
> * Compiler Toolchain -- for GCC, Binutils, Newlib
> * Documentation -- inclusive of all documentation-related issues
> * Trac -- developer wiki, ticket system, etc.
> * Web -- www and ftp issues
> 
> RTEMS Project (*.git) components:
> * RTEMS Coverage
> * RTEMS Examples -- easier if we merge all example repos
> * RTEMS Graphics Toolkit
> * RTEMS libbsd
> * RTEMS Scheduler Simulator
> * RTEMS Source Builder
> * RTEMS Tools
> * RTEMS Tester

I think this sounds like a good start.


> Adding/Removing Components should be locked to admins (if it isn't),
> and should be done by agreement.

Already is.


> Second, there are too many choices for priority and severity. We only
> need 3 levels for each: low, normal, high. They can have different
> names, but 3 is sufficient.

Their is a difference between 'high', 'critical' and 'blocker'.  At the very 
least I think we should have:

blocker  - this ticket must be completed for the release to happen
          (it also cannot be moved)
critical - do it immediately, whoever gets to it first.
high     - these should be done first
normal   - treat it per your discretion
minor    - can be moved to the next milestone easily.


> Third, we should fix Version to get rid of "unknown", "HEAD", and "".
> Tickets must be associated with a version, default to the current
> release series name, e.g. right now 4.11 (but soon 5.0).

'unknown' is being worked on and will go away.  Removing 'HEAD' is good but we 
need to add a note to the ticket page saying 'choose version x.y.z for 
'devel/master'.


> Fourth, we should get rid of the "" in Milestone. Every ticket must be
> given a Milestone.

The new version of trac supports this.  I will see about upgrading one night.  
Same goes for version.


> Fifth, I'm not sure about the value of "keywords". I'd just as soon
> eliminate it.

These are tags and offer a fantastic way to categorise tickets.  It doesn't 
matter what you put there.  For instance over at Buildbot here is our tag cloud:

http://trac.buildbot.net/tags

Pages can also be edited to create content:

http://trac.buildbot.net/wiki/virtualization

Wiki pages can also have tags.  It's a way to amalgamate several different topics 
into one.  There is a tag admin panel that will let us fix spelling issues and 
tags trivially, we can also rename them.

I'd rather see us have a solid attempt to use these before getting rid of it.


> Sixth, finally, I'd rather just see two choices for Type, "defect" and
> "enhancement". A ticket either identifies something broken, or
> proposes something new. "task" is an enhancement as it encompasses
> something to do that improves RTEMS Project. "infra" may be either,
> and Component should identify the infrastructure that is affected.

A task is something that needs to be done versus an actual issue with RTEMS.  
For instance 'add mailing list archives to ftp.rtems.org'.  This is a task, 
tasks aren't directly related to RTEMS source or other bugs and really should be 
in their own category.

infra is special and will be used in the future.  It will squarely be about the 
physical hardware itself and the services running.  So the FTP daemon but not 
the contents of the FTP.  We're eventually going to have a lot of these infra 
requests as we get larger it's nicer to get used to the type now.


> I think that covers it. Feedback? Approval?

Great writeup!


Amar.