Trac, Workflow...

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


Howdy,

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.

Duke



On Fri, Apr 16, 2010 at 10:13 AM, Will Coleda <will at coleda.com> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>



-- 
Jonathan "Duke" Leto
jonathan at leto.net
http://leto.net


More information about the parrot-dev mailing list