Greg Troxel wrote:
> "Chris Nelson" <[email protected]> writes:
>> I admit to not having looked at how mastertickets is implemented.
...
>
> There is a new table in the database mastertickets with content that
> looks like (this is real data):
> ...
> trac-foo=# select * from mastertickets limit 10; source | dest
> --------+------
> 1081 | 884
> 921 | 1134
> 922 | 1134
> 770 | 1134
> ...
>
> So 1134 depends on 921.
>
> I suspect that mastertickets works this way because 1134 depending on
> 921 is about both tickets, and when you add 921 as blocked-by on
> 1134, you want to see 1134 in blocking: on 921. I am generally in
> favor of having this sort of structure, rather than having dual
> records in both tickets and complicated integrity constraints. The
> way it is either the row is there and the relationship is rendered in
> both tickets, or it isn't - there is no way to get a situation with
> dangling half dependencies.
I agree 100%. I thought it odd that it stored data in two tickets
rather than a table of links between tickets. I'm glad to see that's
not the case.
>...
> I was thinking that on a milestone view one would see all tickets on
> that milestone, unless the ticket is a child of a ticket on that
> milestone, and that parent ticket is either shown or been suppressed.
> At least that's how I interpret SubTickets - but now we are having a
> complicated discussion which is why I don't want to change the
> milestone views at all right now.
OK.
>...
>>> Scheduling is probably on my list too - just not my immediate
>>> problem. I don't think there is a conflict between WBS and
>>> scheduling.
>>
>> I agree. It'd be great if you went after WBS and I went after
>> scheduling and we advanced toward PM on two fronts. Getting an
>> architecture laid out on my PM ideas page should help us cooprate.
>
> Is it ok if I go edit there?
Absolutely!
> I think we need to have:
>
> express WBS structure in tickets (my childtickets proposal)
Yes.
> change the way we do estimates (timingandestimation is close and
> with slight semantic tweaks will be exactly right)
What do you have in mind?
> add a way to express resources
I had considered the ticket owner to be the assigned resource. How do
you see that differently?
> add a scheduling component (hard queestion about computing on the
> fly vs storing a computed schedule)
Yeah. Responsiveness could suck if you had to always recompute the
whole schedule. I imagined a pre-computed schedule and a ticket change
listener that would propagate changes.
> how to integrate with external time recording systems
>
> add a reporting/gantt/etc.
Initially, there's benefit in having Start and Finish in a ticket
report. That could form the basis of a gannt, pert, etc.
> and most of that is discussed, but may need more of an architecture
> section.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
