"Chris Nelson" <[email protected]> writes: > I admit to not having looked at how mastertickets is implemented. I > *thought* it stored blocked/blockedby in additional fields of the > ticket. Perhaps it does and you're talking about a new table for > parent/child.
There is a new table in the database mastertickets with content that
looks like (this is real data):
trac-foo=# \d mastertickets
Table "public.mastertickets"
Column | Type | Modifiers
--------+------+-----------
source | text | not null
dest | text | not null
Indexes:
"mastertickets_pk" PRIMARY KEY, btree (source, dest)
trac-foo=# select * from mastertickets limit 10;
source | dest
--------+------
1081 | 884
921 | 1134
922 | 1134
770 | 1134
1137 | 1136
1169 | 286
1183 | 1181
116 | 1184
774 | 1175
1188 | 1189
(10 rows)
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'm not entirely happy with the SubTickets proposal either but it may
> guide this work, even if only providing an example of something we don't
> like and don't want to do. ;-)
I don't fully understand it, and I think there is some merit in a lot of
the notions. It's just too much for me right now.
>> and subtickets on earlier milestones, so I
>> don't want to simply suppress subtickets.
>
> I'm not sure I see how that would work.
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.
>> I would say that A does not get allocated resources, just AA and AB,
>> and A's planned start time is the earlier of AA and AB, and planned
>> end the later, and that's that. In your example AA will be done in 4
>> days and AB 7.5 so that's A's finish time.
>
> I wasn't thinking of actually allocating resources to the parent tasks
> but in, say, a Gantt where you show the parent task with the child tasks
> hidden, it'd be nice to have a balloon pop up when you hover over the
> parent task that showed how much the resources were assigned or consumed
> by the task.
Sure, A gets the hours of both people and the schedule, just like if you
hadn't split and had the resources on A. That sounds fine to me.
>> 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? I think we need to have:
express WBS structure in tickets (my childtickets proposal)
change the way we do estimates (timingandestimation is close and with
slight semantic tweaks will be exactly right)
add a way to express resources
add a scheduling component (hard queestion about computing on the fly
vs storing a computed schedule)
how to integrate with external time recording systems
add a reporting/gantt/etc.
and most of that is discussed, but may need more of an architecture
section.
pgppzOCIEi8qk.pgp
Description: PGP signature
