Trac Ticket Management

Mon Nov 24 02:44:07 UTC 2014

On Sun, Nov 23, 2014 at 6:10 PM, Amar Takhar <amar at rtems.org> wrote:
> On 2014-11-23 14:30 -0500, Gedare Bloom wrote:
>> > Components themselves should be very general.  'RTEMS', 'Build', 'Testing',
>> > 'BSP', 'CPU' etc.
>> >
With the 'arch' field, and ability to tag (e.g. on a bsp name), I
think we only need "RTEMS" component to cover the sources of
rtems.git. It may be nice if we can make 1:1 Components to RTEMS
Project (and external support projects) Repostories.

>> 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.
>
> Keywords/tags are usually single word, space delimited lists it's meant for a
> user to decide what applies or not.  That's what a tag cloud is.
>
> We can modify the ticket page though to add a list of 'useful keywords' to give
> an idea of ones to use.
>
Ok

>
>> Using tags should be fine.
>
> I think we should have one for architecture.  Default it to 'all' but anything
> for a specific architecture should be set.  Users will almost always fill this
> out themselves so there is little work for us.
>
OK, and have a 'none' option too.

>> 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.
>
> Whoops, I forgot we had those two fields enabled.  I'm used to having at least
> one of them disabled.  What you suggested is exactly how I would do it for both
> fields with both defaulting to 'normal'.  I would suggest to add a 'minor' for
> severity so we can let others know it is an item that can be moved trivially.
>
Whatever we call it, I just want 3 levels in each. There is no need
for more. We could check what is in use already for these categories.

>
>> >> 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.
>
> FYI I just deleted the 'unknown' version Joel fixed those.
>
> I made the new default milestone 4.11.1 so any new tickets will default to 4.11
> for version and 4.11.1 for milestone.
>
That is fine for pre-release.

> 5 is really going to be it's own beast I don't think anyone will want to wait
> for that to fix a 4.11 issue unless it requires large changes.
>
>
>> 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.
>
> Then you take away the exact reason tags and keywords exist.  It's the user that
> decides what they are relevant to the issue they are having.  Duplicates are not
> good and we can fix them however we should not limit what can be added.
>
> Most of our tickets are filed by the same set of people.  It's OK if RTEMS
> Source Builder because "RTEMS", "Source", "Builder"  Because if someone wants to
> find all tickets related to source they'll find it.  Same goes for RTEMS.  If
> they search for 'RTEMS Source Builder' they will find it as well.
>
>
>> I see this also as an enhancement to the www component. My guess is
>> most tasks can be framed as (proposed) enhancements.
>
> Here are tasks in Buildbot:
>
> http://trac.buildbot.net/query?status=accepted&status=assigned&status=new&status=reopened&type=task&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=version&order=priority
>
> A task is really just a task, it is a TODO of items that need to be completed
> and nothing more.
>
>
OK, I don't particularly care for it but maybe someone will use it
effectively. (Perhaps this is a work-around for the lack of
dependencies in Trac.)

>> 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
>
> No, it's a whole entire set of tickets that is logically separated from
> everything else.
>
OK we'll see how it develops.

>
>> 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.
>
> The interface will still be simple.  Hardly anyone will ever touch the ticket
> type.  I've never run into a case using trac where is confusing -- that includes
> project that have over a dozen ticket types.  Anyone submitting a ticket will
> know if they're going to use any of the other types.  Anyone who doesn't know
> what to do will leave it as the default.
>
> I'm more of a fan of trying things first and seeing what comes of it.  We can
> always remove the type, severities and other bits if they are unused or become
> burdensome.  Removing it before seeing how things go could end up removing
> features that will help us out in the long run.
>
>
> Amar.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel