in case of alap: ticket starts earlier than its predecessor ticket finishes

[falkb]

Predecessor means to me that it has to be finished before its successor can start.

Function _schedule_task_alap() actually must consider the latest finish time of the predecessor but it does not. It just considers successors and parents somehow. So I can see that some tickets starts earlier than their predecessor finish.

For a test, you must not explicitely set start and end dates at all. It's enough to set some successor and predecessor dependencies.

[Chris Nelson]

I'm in the thick of a major rewrite of the scheduling parts, including resource-based scheduling. I hope to post an update in a week or so and will try to make sure it addresses this case.

[falkb]

Still watching this bug after the latest refactoring on 30/Dec/2011.

More details for the bug environment: I've set:

fields.pred = blockedby
fields.succ = blocking
fields.parent = parents

I also have about 50 tickets in a milestone, about 5 of them are parent tickets for grouping the others. And I'm too lazy to set all start and end dates, so I just have set start and end date of the parent tickets. Additionally, I've set a succession order for all parent tickets. That means this way I don't need to set any schedule information in the child tickets, everything has been put in the parent tickets.

The error

But all my parent tickets start on the same day in the chart, although that succession set by fields.pred and fields.succ

[Chris Nelson]

Replying to falkb:

Still watching this bug after the latest refactoring on 30/Dec/2011.

More details for the bug environment: I've set:

fields.pred = blockedby
fields.succ = blocking
fields.parent = parents

I also have about 50 tickets in a milestone, about 5 of them are parent tickets for grouping the others. And I'm too lazy to set all start and end dates, so I just have set start and end date of the parent tickets. Additionally, I've set a succession order for all parent tickets. That means this way I don't need to set any schedule information in the child tickets, everything has been put in the parent tickets.

The error

But all my parent tickets start on the same day in the chart, although that succession set by fields.pred and fields.succ

Can you attach a screen shot? Perhaps narrow this down to 2-4 tickets so I can easily create the same dependency in my system? Just for completeness, the trac-jsgantt and TracPM sections of your trac.ini would be nice.

[falkb]

It'll take a while to get back to my test bench. It should be enough to create a milestone with those 4 simple tickets:

• A
  • is a child ticket of C
  • has 40 planned and 40 remaining hours
  • has no planned start and end time
• B
  • is a child ticket of D
  • has 40 planned and remaining hours
  • has no planned start and end time
• C
  • is a parent of A
  • is a predecessor of D
  • has no planned and remaining hours
  • has no planned start and end time
• D
  • is a parent of B
  • is a successor of C
  • has no planned and remaining hours
  • has no planned start and end time

Then the chart will display C and D starting at the same day and the dependency arrow from C to D goes back in the past

[anonymous]

Replying to ChrisNelson:

Can you attach a screen shot?

[TracPM]
date_format = %Y-%m-%d
days_per_estimate = 0.125
fields.estimate = estimatedhours
fields.finish = userfinish
fields.parent = parents
fields.pred = blockedby
fields.start = userstart
fields.succ = blocking
fields.worked = totalhours
milestone_type = milestone

[ticket-custom]
billable = checkbox
billable.label = Billable?
billable.order = 3
billable.value = 1
blockedby = text
blockedby.label = Blocked By
blocking = text
blocking.label = Blocking
estimatedhours = text
estimatedhours.label = Planned Hours
estimatedhours.order = 1
estimatedhours.value = 8
hours = text
hours.label = Add Hours to Ticket
hours.order = 2
hours.value = 0
parents = text
parents.label = Parent Tickets
remaininghours = text
remaininghours.label = Remaining Hours
remaininghours.order = 1
remaininghours.value = 8
totalhours = text
totalhours.label = Total Hours
totalhours.order = 4
totalhours.value = 0
userfinish = text
userfinish.label = Planned Finish
userfinish.order = 4
userfinish.value = 
userstart = text
userstart.label = Planned Start
userstart.order = 4
userstart.value = 

[Chris Nelson]

I've reproduced this locally. I'll see what I can do.

[Chris Nelson]

I'm a big mystified why A takes 8 days and B takes 7.

[falkb]

Yes, I checked again and both are really set to 40 hours, as written above. I didn't already noticed that 8 vs. 7 problem. :)

P.S.: You can remove 9566.JPG. I haven't got permissions to change or delete.

[Chris Nelson]

The problem appears to be the dependency between tickets with no estimate. The scheduler computes start + default_estimate = finish and propagates that from parent to child (the default estimate of 4 hours rounds to show a one-day offset). The chart then ignores dates for parents and rolls up values from children so the parent tasks stretch to encompass the duration of their child(ren).

When I configure default_estimate to 0, the tasks all line up on the same day.

Now that I know where it's going wrong, I have to figure out how to propagate durations better.

[Chris Nelson]

Replying to falkb:

... P.S.: You can remove 9566.JPG. I haven't got permissions to change or delete.

Neither have I.

[Chris Nelson]

The essence of the problem seems to be that a group (parent) finish is based on:

1. An explicit date, if any
2. The earliest successor start
3. The latest ancestor finish
4. The latest descendant finish

and its start is based on:

1. An explicit date, if any
2. The finish minus hours, if specified
3. The earliest descendant start

I have not yet accounted for the last term in each of those lists.

[Ryan J Ollos]

Replying to falkb:

P.S.: You can remove 9566.JPG. I haven't got permissions to change or delete.

Removed.

[falkb]

Replying to ChrisNelson:

1. An explicit date, if any
2. The earliest successor start
3. The latest ancestor finish
4. The latest descendant finish

The latest predecessor finish also. Don't know what is more important if there is too less time between set predecessor finish and set successor start.

[falkb]

Replying to falkb:

The latest predecessor finish also. Don't know what is more important if there is too less time between set predecessor finish and set successor start.

But that is just important for the parent start.

[falkb]

Replying to rjollos:

Removed.

wrong one :) We need the image file suffix in lower case. Can you rename it?

[Ryan J Ollos]

Yeah, sorry about that. Should be fixed now.

[falkb]

Replying to anonymous:

Replying to ChrisNelson:

Can you attach a screen shot?

If you look at the image, you may also wonder if it's right to have the bars in the past month. Remember neither the milestone nor the tickets have any set timestamps when they begin and end. In this case I tend to expect the beginning of the first gantt char bar at the current day (blue week).

[Chris Nelson]

This actually signals a more general problem which is turning out to be hard to fix, especially in anticipation of resource leveling.

[falkb]

Replying to ChrisNelson:

This actually signals a more general problem which is turning out to be hard to fix, especially in anticipation of resource leveling.

Then maybe it's better to swap this out to an extra ticket

[Chris Nelson]

Replying to falkb:

Replying to ChrisNelson:

This actually signals a more general problem which is turning out to be hard to fix, especially in anticipation of resource leveling.

Then maybe it's better to swap this out to an extra ticket

My "this" referred to the ticket summary, not "should an ALAP schedule end today or make-span from today. It's a hard problem that the naive algorithm neglects. Working on it...

[Chris Nelson]

I may have a nice, general solution which will handle resource leveling but I can't get it to work because of either a bug in Trac or Python or my misunderstanding of deepcopy(). My question to ​trac-dev hasn't gotten any response.

[Chris Nelson]

​http://grokbase.com/p/python.org/python-list/2009/01/how-to-deepcopy-a-list-of-user-defined-lists/08o7x4coflamidhtsvod2ewoluna notes:

A subclass of list should populate the list in __init__, not __new__, usually by calling list.init, as lists are mutable and subclasses thereof should be too.

I don't believe TracPM has any subclass of list and I think Ticket maybe which suggests to me there's something wrong in Trac core.

[anonymous]

you may also find this useful for looking through: ​http://bytes.com/topic/python/answers/101464-more-deepcopy-tkinter

Note: Strange, some comments of a few minutes ago are missing

[Ryan J Ollos]

Replying to anonymous:

Note: Strange, some comments of a few minutes ago are missing

That was my fault. I delete a lot of spam, and some of the recent comments, without given much thought, looked to be spam. I'll try to be more careful.

[anonymous]

No worries. We've still got the emails... somehow it was spam as well ;)

[falkb]

Replying to ChrisNelson:

​trac-dev

I slightly wonder why you want to copy a ticket deep down. Isn't it enough to just grab the common and custom fields including their value, and build up your desired dicts with that information?

[Chris Nelson]

Replying to falkb:

Replying to ChrisNelson:

​trac-dev

I slightly wonder why you want to copy a ticket deep down. Isn't it enough to just grab the common and custom fields including their value, and build up your desired dicts with that information?

My scheduler could copy just the fields it cares about and work in a scratch space -- and that may be the approach I take if I can't resolve this -- but it's more general if TracPM.computeSchedule() gives the scheduler a set of tickets it can write all over.

OTOH, I tried:

• Back up certain fields (with copy)
• Schedule (overwriting original values)
• Assign fields back to copied value

and the copy seemed to have no effect. <shrug>

[falkb]

​http://tinypaste.com/1a0ff869 - A snippet of my patch for #6168 where I successfully used deepcopy() for reusing the options list. Hope this helps.

[falkb]

Replying to falkb:

#6168

argh... I mean #6186

[Chris Nelson]

Replying to falkb:

​http://tinypaste.com/1a0ff869 - A snippet of my patch for #6168 where I successfully used deepcopy() for reusing the options list. Hope this helps.

I don't see how it applies as I'm trying to copy a ticket and I've been advised on trac-dev that that can't work (Ticket is simply a derivative of a Python list). Even doing field-by-field copies (or deep copies) doesn't seem to help. Using your test case and:

        # I can't deep copy tickets so let's save what we're going to
        # mess up so we can put it back.
        # FIXME - this doesn't work, either. <shrug>
        pred = {}
        succ = {}
        for tid in ticketsByID:
            # Neither copy or deepcopy here make a difference
            pred[tid] = copy.deepcopy(ticketsByID[tid][self.pm.fields['pred']])
            succ[tid] = copy.deepcopy(ticketsByID[tid][self.pm.fields['succ']])

        # Main schedule processing
        _augmentTickets(ticketsByID)

        for id in ticketsByID:
            if options['schedule'] == 'alap':
                _schedule_task_alap(ticketsByID[id])
            else:
                _schedule_task_asap(ticketsByID[id])

        for tid in ticketsByID:
            # This doesn't work with or without copy.
            ticketsByID[tid][self.pm.fields['pred']] = copy.copy(pred[tid])
            ticketsByID[tid][self.pm.fields['succ']] = copy.copy(succ[tid])

the augmented dependencies how up in the chart. I'm boggled.

[falkb]

you should go to IRC and try to get enlighted there...

[Chris Nelson]

I have a working fix for this but I'm integrating it into our system and verifying it. I hope to post this weekend or early next week.

[Chris Nelson]

(In [11141]) Clarify some comments. Add a FIXME. Refs #9566.

Also a couple of minor white space tweaks.

[Chris Nelson]

(In [11143]) Pass scheduler tickets by ID, not unordered list. Refs #9566.

Any scheduler will need a fast lookup of tickets by ID so this takes the work of building that lookup off the schedulers, reducing duplicated code.

It also copies the ticket attributes so that the scheduler can change them without concern that it will break things. This enforces the pre- and post-conditions for computeSchedule() that only 'calc_start' and 'calc_finish' are set/changed.

It would seem that I could done

        for t in tickets:
            ticketsByID[t['id']] = copy.deepcopy(t)

but that raised errors.

[Chris Nelson]

(In [11144]) Tasks inherit their ancestors' dependencies. Refs #9566.

If A has children B and C, and D has children E and F, if A is required for D then B and C have to be completed before D.

This copies predecessor and successor dependencies down the tree before scheduling so those dependencies can be honored by the scheduler.

It uses functions as objects and takes advantage of the fact that the accessor functions don't return values, they return references to the original lists so those lists can be updated without more complicated access wrappers to append, remove, etc.

Also fix a bug in creating milestone pseudotickets where [] and None were not used consistently with the rest of the module.

[falkb]

Thanks! Seems 2012 will be a good year for TracJsGanttPlugin. Seems to work well, anyway, it looks already good on my test bench with the small test project A-B-C-D. I'm going to test it on the big real-life project tommorrow. Cool that weekends are considered also.

As noticed in 18, my example scenario still ends today and starts in the past. The milestone has not date set. I think a solution in the case of no milestone date set would be to add a time shift to all tickets which is equal to today minus earliest computed ticket date. This is of quite great importance here, since we schedule a project by ticket hierarchy but without setting a milestone date yet. Simply, since that milestone date depends on from what the ticket scheduling results to. We want to have a look to which date the Gantt chart will lead us and take it as hint for setting the milestone date then. But as mentioned before, this may be another ticket. It's not quite related to this dependency problem of this #9566.

[falkb]

Replying to falkb:

on the big real-life project tommorrow

Yeah, dependencies look good here too :-)

As noticed in 18, my example scenario still ends today and starts in the past. The milestone has not date set.

As a test, I switched to mode schedule=asap. Then the good news is the whole thing starts the computation from date 'today'. Though the milestone is put on 'today', therefore not appended to the bottom of the list but inserted quite early, and that lets the chart look a bit strange:

First in 37, I thought that's a story for another ticket, but I think the milestone must be treated like something like a ticket as well. That means the rule should be a milestone without set date (internally) is the successor of all its assigned tickets and therefore must be displayed as last date point in the chart.

[falkb]

milestone inserted too early

[Chris Nelson]

Replying to falkb:

.... That means the rule should be a milestone without set date (internally) is the successor of all its assigned tickets and therefore must be displayed as last date point in the chart.

I agree. Which is why I have:

                # Any ticket with this as a milestone and no
                # successors has the milestone as a successor
                if self.isCfg(['pred', 'succ']):
                    pred = []
                    for t in tickets:
                        if not t['children'] and \
                                t['milestone'] == row[0] and \
                                self.successors(t) == []:
                            if self.isField('succ'):
                                t[self.fields[self.sources['succ']]] = \
                                    [ str(id) ]
                            else:
                                t['succ'] = [ str(id) ]
                            pred.append(str(t['id']))
                    if self.isField('pred'):
                        milestoneTicket[self.fields[self.sources['pred']]] = \
                            pred
                    else:
                        milestoneTicket['pred'] = pred

but when I looked at that just now, I found it is preceded by:

                # If there's no due date, default to today at close of business
                if self.isCfg('finish'):
                    ts = row[1] or \
                        (datetime.now(utc) + 
                         timedelta(hours=options['hoursPerDay']))
                    milestoneTicket[self.fields['finish']] = \
                        format_date(ts, self.dbDateFormat)

                    # jsGantt ignores start for a milestone but we use it
                    # for scheduling.
                    if self.isCfg('start'):
                        milestoneTicket[self.fields['start']] = \
                              milestoneTicket[self.fields['finish']]

Which sets a finish date we don't. It may be as simple as removing the code that sets the milestone finish and let the scheduler fill it in after computing dependencies. Can you try that? It would take a while for me to set up a test.

[falkb]

Replying to ChrisNelson:

... It may be as simple as removing the code that sets the milestone finish

Well, just a snapshot:

If I comment out lines 565 and 566 to remove the setting of milestone finish I get:

...
  File "build\bdist.win32\egg\tracjsgantt\tracpm.py", line 717, in postQuery
    self._add_milestones(options, tickets)
  File "build\bdist.win32\egg\tracjsgantt\tracpm.py", line 572, in _add_milestones
    milestoneTicket[self.fields['finish']]
KeyError: u'userfinish'

If I additionally comment out lines 570-572 to also remove the setting of milestone start I get:

...
  File "build\bdist.win32\egg\tracjsgantt\tracjsgantt.py", line 559, in _add_tasks
    self.pm.computeSchedule(options, self.tickets)
  File "build\bdist.win32\egg\tracjsgantt\tracpm.py", line 732, in computeSchedule
    self.scheduler.scheduleTasks(options, ticketsByID)
  File "build\bdist.win32\egg\tracjsgantt\tracpm.py", line 1207, in scheduleTasks
    _schedule_task_asap(ticketsByID[id])
  File "build\bdist.win32\egg\tracjsgantt\tracpm.py", line 1065, in _schedule_task_asap
    if self.pm.isSet(t, 'start'):
  File "build\bdist.win32\egg\tracjsgantt\tracpm.py", line 216, in isSet
    and len(ticket[self.fields[field]]) != 0:
KeyError: u'userstart'

[Chris Nelson]

Replying to falkb:

Replying to ChrisNelson:

... It may be as simple as removing the code that sets the milestone finish

Well, just a snapshot:

If I comment out lines 565 and 566 to remove the setting of milestone finish I get: ...

Thanks. I hoped it would be easy. I'll try to look into this today.

[Chris Nelson]

(In [11153]) Don't force a due date on unscheduled milestones. Refs #9566.

An unscheduled milestone no longer defaults to being due today but gets its date from the scheduler.

[falkb]

Replying to ChrisNelson:

(In [11153]) Don't force a due date on unscheduled milestones. Refs #9566.

An unscheduled milestone no longer defaults to being due today but gets its date from the scheduler.

Not bad, but not perfect.

My milestone behaviour test is like this:

• ticket duration range some weeks
• 2 milestones
  • milestone1 with date in 3 days
  • milestone2 without date
• Test of schedule=alap:

milestone	expected	seen
1	between the tickets on its certain date	wrong, is at the bottom below all tickets, set date overruled by date after all other tickets
2	at the bottom below all tickets	correct, as expected

• Test of schedule=asap:

milestone	expected	seen
1	between the tickets on its certain date	correct, as expected
2	at the bottom below all tickets	wrong, is at the top before all tickets

[Chris Nelson]

Replying to falkb:

Replying to ChrisNelson:

(In [11153]) Don't force a due date on unscheduled milestones. Refs #9566.

An unscheduled milestone no longer defaults to being due today but gets its date from the scheduler.

Not bad, but not perfect.

My milestone behaviour test is like this:

• ticket duration range some weeks
• 2 milestones
  • milestone1 with date in 3 days
  • milestone2 without date
• Test of schedule=alap:

milestone	expected	seen
1	between the tickets on its certain date	wrong, is at the bottom below all tickets, set date overruled by date after all other tickets
2	at the bottom below all tickets	correct, as expected

• Test of schedule=asap:

milestone	expected	seen
1	between the tickets on its certain date	correct, as expected
2	at the bottom below all tickets	wrong, is at the top before all tickets

A screen shot would help.

[falkb]

Replying to ChrisNelson:

Replying to falkb:
A screen shot would help.

Here we go:

• milestone1 with set date
• milestone without date

• Test of schedule=alap:

milestone	expected	seen
1	between the tickets on its certain date	wrong, is at the bottom below all tickets, set date overruled by date after all other tickets
2	at the bottom below all tickets	correct, as expected

---

• Test of schedule=asap:

milestone	expected	seen
1	between the tickets on its certain date	correct, as expected
2	at the bottom below all tickets	wrong, is at the top before all tickets

[falkb]

Hmm... uploading images doesn't work anymore. You can find them also here: ​alap image and ​asap image

(Due 14-days timeout, you can locally attach them to this ticket after someone has repaired the image handling on the server)

[osimons]

I've deleted the images. Seeing '#' is the fragment identifier in URLs, I'm not surprised that that this old Trac has trouble with using it in filenames - makes it hard to access them when the URL isn't encoded correctly.

BTW, try to upload them to ​http://trac.edgewall.org/demo-0.12 or similar to see if the issue is fixed in current Trac.

[Chris Nelson]

Replying to falkb:

Hmm... uploading images doesn't work anymore. You can find them also here: ​alap image and ​asap image

(Due 14-days timeout, you can locally attach them to this ticket after someone has repaired the image handling on the server)

milestone1 appears to have no dependencies and to show up on 1/26 in both schedules.

It does seem that milestone2 should be below the tasks it depends on in the ASAP schedule.

[falkb]

illustrating 45, schedule=alap

[falkb]

illustrating 45, schedule=asap

[falkb]

Replying to osimons:

'#' is the fragment identifier in URLs

Argh... my fault! Sorry for the trouble. Could you do me a favour and rename the image names used in the macros of comment:45, please? All related comments can be be deleted, too. TIA

[falkb]

now comment 45 again with fixed images:

Replying to ChrisNelson:

Replying to falkb:
A screen shot would help.

Here we go:

• milestone1 with set date 1/26
• milestone without date

• Test of schedule=alap:

milestone	expected	seen
1	between the tickets on its certain date	wrong, is at the bottom below all tickets, set date overruled by date after all other tickets
2	at the bottom below all tickets	correct, as expected

You can see, because of set date 1/26, milestone1 is wrong and should actually be between the tickets on its certain date.

---

• Test of schedule=asap:

milestone	expected	seen
1	between the tickets on its certain date	correct, as expected
2	at the bottom below all tickets	wrong, is at the top before all tickets

You can see, because of no set date, milestone2 is at wrong position and should be at the botton below all tickets at the end.

[falkb]

Both images are not full screenshots but just puzzle pieces of the whole chart, and the ticket texts are obliterated since it's from a real project chart. The chart contains the range of two milestones where just milestone2 has no date because that should more or less be set from what the chart computes.

[Chris Nelson]

Replying to falkb:

Both images are not full screenshots but just puzzle pieces of the whole chart, and the ticket texts are obliterated since it's from a real project chart. The chart contains the range of two milestones where just milestone2 has no date because that should more or less be set from what the chart computes.

I understand that you're showing me just a piece of the whole chart but...

• ALAP
  • MS1 has an explicit date of 1/26 and shows up there
  • MS2 is scheduled today, 1/17 (which you could argue is wrong, but it's what I expectg)
  • Tasks are sorted by date so (roughly) later tasks are lower in the list
  • MS1 is later than MS2 so it is lower.

What's wrong with that?

• ASAP
  • MS1 has an explicit date of 1/26 and shows up late in the week of 1/22, this looks right to me
  • MS2 shows up today which does seem wrong to me, it should follow its latest prececessor, perhaps 2118. (I believe that it shows up above the tasks because of correct date sorting after incorrect scheduling)

I'll try to set up your data as an ASAP test case soon.

[Chris Nelson]

Replying to ChrisNelson:

...

• ASAP
  • MS1 has an explicit date of 1/26 and shows up late in the week of 1/22, this looks right to me
  • MS2 shows up today which does seem wrong to me, it should follow its latest prececessor, perhaps 2118. (I believe that it shows up above the tasks because of correct date sorting after incorrect scheduling)

Is this after the recent patch that took off the default of today for unscheduled milestones?

[falkb]

Replying to ChrisNelson:

Replying to falkb:

Both images are not full screenshots but just puzzle pieces of the whole chart, and the ticket texts are obliterated since it's from a real project chart. The chart contains the range of two milestones where just milestone2 has no date because that should more or less be set from what the chart computes.

I understand that you're showing me just a piece of the whole chart but...

• ALAP
  • MS2 is scheduled today, 1/17 (which you could argue is wrong, but it's what I expectg)

What's wrong with that?

You agreed in 39 that a milestone without set date (internally) is the successor of all its assigned tickets. That's why milestone2 cannot be scheduled today.

• ASAP
  • MS1 has an explicit date of 1/26 and shows up late in the week of 1/22, this looks right to me
  • MS2 shows up today which does seem wrong to me, it should follow its latest prececessor, perhaps 2118. (I believe that it shows up above the tasks because of correct date sorting after incorrect scheduling)

Look at my two tables in 50 with expected and seen behaviour of the two milestones. That milestone2 should be scheduled as last one because of the rule already mentioned above.

[falkb]

Replying to ChrisNelson:

Is this after the recent patch that took off the default of today for unscheduled milestones?

Do you mean the suggested code removing in 39? That didn't work, so I'm on the latest SVN version without local patches.

[Chris Nelson]

Replying to falkb:

Replying to ChrisNelson:

Replying to falkb:

Both images are not full screenshots but just puzzle pieces of the whole chart, and the ticket texts are obliterated since it's from a real project chart. The chart contains the range of two milestones where just milestone2 has no date because that should more or less be set from what the chart computes.

I understand that you're showing me just a piece of the whole chart but...

• ALAP
  • MS2 is scheduled today, 1/17 (which you could argue is wrong, but it's what I expectg)

What's wrong with that?

You agreed in 39 that a milestone without set date (internally) is the successor of all its assigned tickets. That's why milestone2 cannot be scheduled today.

Milestone2 *is* shown as a successor to all of its tickets. I understand that anchoring an ALAP schedule without explicit dates so it ends today is questionable but given that is the current algorith, MS2 shows up in the correct position relative to its tickets.

• ASAP
  • MS1 has an explicit date of 1/26 and shows up late in the week of 1/22, this looks right to me
  • MS2 shows up today which does seem wrong to me, it should follow its latest prececessor, perhaps 2118. (I believe that it shows up above the tasks because of correct date sorting after incorrect scheduling)

Look at my two tables in 50 with expected and seen behaviour of the two milestones. That milestone2 should be scheduled as last one because of the rule already mentioned above.

I'm sorry if I'm dense today but what rule? MS1 shows up on its due date. MS2 is clearly on the wrong date.

I see two new tickets here:

• In ALAP scheduling, today is not a valid end date if no dates are assigned
• In ASAP scheduling, milestones don't show up after their tickets, everything seems to start today.

[Chris Nelson]

Replying to falkb:

Replying to ChrisNelson:

Is this after the recent patch that took off the default of today for unscheduled milestones?

Do you mean the suggested code removing in 39? That didn't work, so I'm on the latest SVN version without local patches.

My suggestion was flawed/incomplete but I finished it in 42. That's the change I'm talking about.

[falkb]

Replying to ChrisNelson:

My suggestion was flawed/incomplete but I finished it in 42. That's the change I'm talking about.

I use the latest of the SVN trunk

[falkb]

Replying to ChrisNelson:

I'm sorry if I'm dense today but what rule?

I'm talking about this rule: a milestone without set date (internally) is the successor of all its assigned tickets

MS1 shows up on its due date.

milestone	expected	seen
1	between the tickets on its certain date	correct, as expected

MS2 is clearly on the wrong date.

milestone	expected	seen
2	at the bottom below all tickets	wrong, is at the top before all tickets

=> I'm glad that, for the case of ASAP, we see the same problem. I used a table, you said the same in sentences.

[falkb]

Replying to ChrisNelson:

...

For ALAP: Let me put it in other words. 54 and 56 were totally confusing. :)

Here my ALAP table again:

milestone	expected	seen
1	between the tickets on its certain date	wrong, is at the bottom below all tickets, set date overruled by date after all other tickets
2	at the bottom below all tickets	correct, as expected

• ALAP
  • MS1 has an explicit date of 1/26 and shows up there

No, it doesn't show up there on 1/26. The date is 1/26 but shows up many weeks later after all other tickets, and that's why it's at the botton of the table, and such behaviour is wrong. As written in my table, I've seen the set date of MS1 is overruled by a date which is after all other tickets. I expect MS1 to show up between the tickets on its certain date on 1/26.

• MS2 is scheduled today, 1/17 (which you could argue is wrong, but it's what I expectg)

Right, MS2 is correct as the table says as well in column seen, line of milestone 2.

• Tasks are sorted by date so (roughly) later tasks are lower in the list

Right, but MS1 is the lowest although it should be one of the earliest on 1/26. Look here again and see it long after its proper date:

Though, you are right when you write at the end of 56: "In ALAP scheduling, today is not a valid end date if no dates are assigned"

[falkb]

Replying to ChrisNelson:

I see two new tickets here:

• In ALAP scheduling, today is not a valid end date if no dates are assigned
• In ASAP scheduling, milestones don't show up after their tickets, everything seems to start today.

Right, seems it's been a hard birth, either here in #9566 or two new ones. P.S.: Clear explanations are difficult to phrase, last but not least since English is not my mother tongue. :)

[Chris Nelson]

The original subject of this ticket has been successfully addressed.

[Chris Nelson]

(In [11159]) Optimize dependency propagation to children. Refs #9566.

In my 6-ticket test case, this reduces the number of dependencies added from 8 to 3. In general, I think that the potential arcs in a graph are the number of nodes squared so in real-world data sets, this improvement is likely even bigger.

[anonymous]

Replying to ChrisNelson:

I see two new tickets here:

• In ALAP scheduling, today is not a valid end date if no dates are assigned

continued on #9705

• In ASAP scheduling, milestones don't show up after their tickets, everything seems to start today.

continued on #9704

Replying to ChrisNelson:

(In [11159]) Optimize dependency propagation to children. Refs #9566. ... so in real-world data sets, this improvement is likely even bigger.

Very good. I already noticed when resizing the browser window with a chart of about 100 tickets that the slowlyness was sensible on IE before (FF is much faster). But now with your commit it's acceptably fast. I already thought about bothering with a new ticket for that but [11159] refrains me from doing so... :)

[Chris Nelson]

(In [11402]) Try to propagate dependencies to all children. Refs #9566.

This actually seems to get back to the original implementation. I broke it trying to optimized.

The logic now and originally is:

for each child
   if the child doesn't depend on any cousins
      copy dependencies down
   recurse to process grandchildren

The optimized, broken, intermediate version did:

if there are dependencies
   for each child
      copy dependencies down
      recurse to process grandchildren

If any level of the tree had no dependencies, propagation was interrupted. If a "root" ticket had no dependencies, all of its descendants were ignored.

[falkb]

[11402] tested with success