Trac, Workflow...

Jonathan Leto jaleto at
Fri Apr 16 21:26:39 UTC 2010


I am pretty much +1 to everything that was said. I am on the fence
about whether to open a new ticket for testing something. I think it
depends on the circumstances of the ticket and how hard the tests will
be to implement.


On Fri, Apr 16, 2010 at 10:13 AM, Will Coleda <will at> wrote:
> After recent discussion about bugs not standing out in trac, I'd like
> to make some suggestions and get some feedback:
> Ticket Types:
> -------------------
> We currently have the following ticket types. Some of this information
> can be more easily tracked via other mechanisms. I think we can get
> away with these three types and ditch the rest.
> *bug (289)
> These are actual bugs. Features that are intended to work, code is
> there, but for some reason it doesn't work.
> This should probably be the default ticket type until a bug is
> triaged. Our users aren't going to care about our internal workflow.
> * todo (157)
> These are should indicate items that are not yet implemented, but the
> team agrees they should be.
> * RFC (65)
> This is like a todo, but it requires a discussion before it goes onto
> the todo pile. These tickets probably need to be hashed out on the
> mailing list, or in #parrotsketch. There's just not enough traffic on
> the tickets list for these to get a community review in trac. If
> there's a compelling reason for a developer in charge of a component
> to reject, note it and close the ticket.
> * feature (23)
> Not sure what the purpose of this one is. Looking at the existing
> tickets, looks like this is the same as TODO or RFC, so let's retag
> them.
> * cage (37)
> These were meant to indicate issues with items that are not feature
> related. Perhaps a coding standards issue (e.g. a refactor). This
> status can go away, and can be deal with with the priority flag. These
> are bugs or todos.
> * patch (33)
> A patch has been submitted. This category needs to go away. We already
> have a patch status field, and the patch is either to fix a bug or add
> a feature. These are either RFCs, todos, or bugs.
> * roadmap
> These are high level TODO tickets; They make more sense as
> roadmap-priority TODOs, if they are worth keeping at all. (see
> workflow, below).
> * deprecation (24)
> * experimental (5)
> These were an experiment to help us track things for the support
> policy. I think they're just confusing the situation now.
> deprecation is a TODO with a specific time frame - It's tempting to
> put the earliest possible release we can remove it from in the
> milestone - but that prevents the milestone from being closed if the
> ticket is incomplete; do we mind if we can't mark a milestone as
> complete because of this? I think just putting it in the summary of
> the ticket like we did before is sufficient, e.g. the deprecation
> ticket "[TODO] Migrate non-essential PMCs to dynpmcs" should probably
> be a todo ticket with a summary of "Migrate non-essential PMCs to
> dynpmcs [incompatible change, anytime after 2.3]
> experimental features are really RFCs that already have code in place.
> I recommend making them RFCs and putting in an "experimental" keyword.
> * spam (0)
> We have the plugin that lets us delete the spam, I think. Let's just
> delete this one..
> Workflow:
> ---------------
> Responding to some suggestions that came up:
> * I don't mind having wiki pages to handle task lists, but, for
> example, "immutable strings" is worthy of a one-liner RFC ticket; the
> individual components of how that gets done can be tracked in the
> wiki, and the ticket can point to that wiki page and the branch the
> work is on. I think these one-liners can be of the same descriptive
> level as the roadmap items - they are just place holders so that
> someone looking at the roadmap can get an overview of what sort of
> work is going on the project, and what they might be able to expect in
> the next release.
> * tests - I don't think it's worthwhile opening a new ticket for
> testing todos. The feature isn't added / the bug isn't fixed until
> there's a test; adding another ticket causes more work for the person
> handing off the task for testing; trac doesn't support formal ticket
> linking, so there are multiple steps involved, and the person writing
> the tests has to go back through the old code anyway. Might be worth
> adding a new ticket property so we can easily say "work is done but
> needs tests".
> --
> Will "Coke" Coleda
> _______________________________________________

Jonathan "Duke" Leto
jonathan at

More information about the parrot-dev mailing list