On Saturday 22 April 2006 10:39, Christian Boos wrote: > > - A ticket has a single optional parent and zero or more children. The > > data is stored in two new fields in the ticket DB table and on the ticket > > object. Accordingly it can be a parameter to /query and so on. > > IIUC, you only want parent/child relationships, no additional > "depends-on" relationships? > Then you should maybe reconsider the limitation of single parenting, as > I think it's > quite common that a ticket "blocks" several others. I was too focused on the view-milestone-as-ticket-tree usecase, but you're right, we need many-to-many depends relationships.
> > > - Both properties can be set, unset and changed through manual editing. > > There are also links such as 'Add child ticket' on ticket pages. > > Have also look at: > - http://projects.edgewall.com/trac/ticket/2193 > - http://projects.edgewall.com/trac/wiki/SubTickets#CreatingSubtickets That agrees nicely with what I want, especially the comments about milestones. On the issue of generifying milestones and non-milestone top-level tickets: if a milestone is just a specially selected top-level ticket, we can implement that with tags and queries. A milestone is any toplevel ticket with the milestone tag. And we wouldn't need a separate /roadmap provider - the roadmap would be displayed as an ordinary query list result. All the special features roadmap displays have today will be merged into the (hierarchical) /query view. > I think you certainly can get away with a plugin approach, especially if > based on the WorkFlow branch. > Then later, if I manage to move the infrastructure for generic Trac > objects and for generic relations between > them in the trunk, you will certainly have a much easier (trivial?) task > in your plugin, at least for the data > storage part. > > In summary, I think that a good UI is certainly the most challenging > part for the parent/child > relationship and I can only encourage you to start something in this > direction. If time permits, > I'd be enthusiastic to help in this area too. For the data storage part, > you'd better create your > own table for now (ticket_hierarchy) and write ad-hoc code; that part > can always be improved > upon later. For the global approach, I'd suggest you go for 4), which I > think is the most > future-proof approach. > > Also, for a new development like that, you should forget about 0.9 > compatibility, > as 0.10 is getting nearer and the WorkFlow branch will jump-start the > development of 0.11. That sounds good. So I'll write a plugin for the workflow branch's new extension points, and will modify /query to be extensible as well. Until now we've used only released Trac versions in our local install. I'm willing to work with the workflow branch and later with 0.12dev since you tell me that workflow /will/ be merged in the forseeable future. Since I haven't worked with trunk or any branches beforehand - what's their usual state in terms of regressions and of forward-porting bugfixes? For instance, 0.9.4 included many small bugfixes, are they also in the workflow branch? Thanks for your help, -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 -- Dan Armak
pgpr08JFmFb9C.pgp
Description: PGP signature
_______________________________________________ Trac-dev mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac-dev
