Trac Ticket Management

[Gedare Bloom]

On Sun, Nov 23, 2014 at 11:10 AM, Amar Takhar <amar at rtems.org> wrote:
> 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.
>
OK, if we define some tags and scope them right, this can work. I
don't like the idea of a free-text field though. Can tags be a
drop-down list like the other fields? So we can define the set of
tags? Either that, or put a link to the tag cloud or an organized tag
list next to the keywords entry box, or similar, to give users (and
forgetful developers) some guidance about what to put there.

> 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.
>
Using tags should be fine.

>
>> * 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.
>
We have two fields, Priority and Severity. Right now, each field has 5
choices. I'd like to reduce these to 3 each.

Priority: High, Normal, Low.  Priority encodes urgency.

Severity: Blocker, Critical, Normal. Severity encodes deferrability.

I would rename Severity->Criticality (leverage real-time jargon!), and
change the values to "High, Normal, Low". High means the problem must
be fixed in the affected versions. Normal means it should be fixed,
but probably can be delayed. Low means it can be delayed without
debate.

The matrix of Priority x Criticality will have some nice meaning also.
High-High corresponds to "get it done immediately", whereas Low-High
means "get it done sometime before release", and so on.

I don't think we need more than 3 levels in either category.

>
>> 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'.
>
Yes. The default behavior also should be to choose the current release
series name, e.g. right now 4.11, when 4.11 is released, the default
milestone will be 5.0.

>
>> 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.
>
As I said above, I'd prefer to do this in a way that limits the sprawl
of tags. Also, tags appear to only work for single words, thus "RTEMS
Source Builder" gets parsed into "RTEMS", "Source", "Builder". This
should be addressed somewhere.

>
>> 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.
>
I see this also as an enhancement to the www component. My guess is
most tasks can be framed as (proposed) enhancements.

> 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 still think this can be framed as either a defect or an enhancement
to the infrastructure. The fact it is for "infrastructure" could be
selected by the tag field? This example could be perhaps, defect in
www component, with three tags: infrastructure, ftp, daemon

I'm mainly looking at how to keep the interface simple, especially for
new users. For a user, the default behavior and drop-down lists should
be easy to understand.

-Gedare