[ckan-dev] How we use trac

[Sean Hammond]

> Similarly, it would be useful to be able to identify which tickets are
> being worked on.  Eg - we have no way of discerning "for 1.9, being worked
> on this iteration" vs. "for 1.9, being worked on next iteration".  It would
> give ticket reporters the ability to see if there ticket was likely to make
> it into 1.9 or not.

One way to do this might be to say that as a dev you only accept a
ticket if you're planning to work on it this iteration. So you may have
many tickets assigned to you with status "assigned" you're only
currently working on the ones with status "accepted"

> new -> accepted -> assigned -> in development [-> awaiting merge] -> closed

I think the workflow goes new -> assigned -> accepted (= in development) -> closed

(and we don't have a special status for awaiting merge, afaik we're just
relying on devs to grab other devs in irc, standup, etc. and get them to
review and merge things)

In actual reality the trac ticket workflow looks kind of non-linear:

http://trac.edgewall.org/wiki/TracWorkflow

> > Ok. It sounds like Nils is probably going to upgrade trac next week
> > which involves a db migration, so lets wait until after that. In the
> > meantime we stick to the old sprint system I think
> >
> 
> Did trac get upgraded?  If so, I'm happy to look at adding this new status
> (and the awaiting-merge one too) if people are if favour of either of them.

It still hasn't been upgraded