Rescheduling not working?

[MattLichter]

I trying to understand the rescheduling capabilities of TracJsGanttPlugin. I am using it in conjunction with the MasterTickets plugin. Imagine the following simple scenario:

Ticket A has a specified finish date. Ticket B has *no* specified start date, and is blocked by Ticket A (by defining the blockedby value in the new ticket panel)

Should Ticket B's start date be auto-scheduled to be the finish date of Ticket A? I am not getting that behavior. The start date just matches the finish date of Ticket B (minus any esimated hours). The gantt chart is otherwise drawn correctly with the dependency lines, so it seems to be otherwise functional.

I have enabled logscheduling and seeing info in my logfile, and I can pass that along if it helps.

Other config info:

System Information

Package	Version
Trac	1.0.1
Babel	0.9.6
Docutils	0.10
Genshi	0.6 (without speedups)
GIT	1.9.0
mod_wsgi	3.5 (WSGIProcessGroup wsgi-trac WSGIApplicationGroup %{GLOBAL})
Pygments	1.6
pysqlite	2.6.3
Python	2.7.6 (default, Aug 14 2014, 16:02:39) [GCC 4.1.2 20070626 (Red Hat 4.1.2-14)]
setuptools	0.6c11
SQLite	3.7.15.1
jQuery	1.7.2
Installed Plugins

Name	Version	Location
timingandestimationplugin	1.4.0b	/opt/bitnami/python/lib/python2.7/site-packages/timingandestimationplugin-1.4.0b-py2.7.egg
Trac-jsGantt	0.10	/opt/bitnami/python/lib/python2.7/site-packages/Trac_jsGantt-0.10-py2.7.egg
TracAccountManager	0.3.2	/opt/bitnami/apps/trac/lib/TracAccountManager-0.3.2-py2.7.egg
TracCustomFieldAdmin	0.2.8	/opt/bitnami/python/lib/python2.7/site-packages/TracCustomFieldAdmin-0.2.8-py2.7.egg
TracDateField	3.0.0dev	/opt/bitnami/python/lib/python2.7/site-packages/TracDateField-3.0.0dev-py2.7.egg
TracMasterTickets	3.0.5dev	/opt/bitnami/python/lib/python2.7/site-packages/TracMasterTickets-3.0.5dev-py2.7.egg
TracSubTicketsPlugin	0.2.0.dev-20141030	/opt/bitnami/python/lib/python2.7/site-packages/TracSubTicketsPlugin-0.2.0.dev_20141030-py2.7.egg

[Chris Nelson]

Replying to MattLichter:

I trying to understand the rescheduling capabilities of TracJsGanttPlugin. I am using it in conjunction with the MasterTickets plugin. Imagine the following simple scenario:

Ticket A has a specified finish date. Ticket B has *no* specified start date, and is blocked by Ticket A (by defining the blockedby value in the new ticket panel)

OK.

Should Ticket B's start date be auto-scheduled to be the finish date of Ticket A? I am not getting that behavior. The start date just matches the finish date of Ticket B (minus any esimated hours). The gantt chart is otherwise drawn correctly with the dependency lines, so it seems to be otherwise functional.

Where did the finish date for B come from? If A is required for B, I'd expect an ASAP schedule to be:

	Specified				Scheduled				Notes
#	A start	A finish	B start	B finish	A start	A finish	B start	B finish
1					Now	Now+AD	Now+AD	Now+AD+BD	No fixed dates, ASAP starts now
2	AS				AS	AS+AD	AS+AD	AS+AD+BD	AS sets schedule, B follows A immediately
3	AS		BS		AS	AS+AD	BS	BS+BD	Both have fixed starts so are AF has no relationship to BS. (The same would be true if we specificed AS and BF.)
4		AF			AF-AD	AF	AF	AF+BD	AF sets schedule, B follows A immediately
5		AF		BF	AF-AD	AF	BF-BD	BF	Both have fixed finishes so are AF has no relationship to BS

And an ALAP scheudle would be:

	Specified				Scheduled				Notes
#	A start	A finish	B start	B finish	A start	A finish	B start	B finish
1					Now-BD-AD	Now-BD	Now-BD	Now	No fixed dates, ALAP finishes now (kind of odd), A precedes B immediately
2	AS				AS	AS+AD	Now-BD	Now
3	AS		BS		AS	AS+AD	BS	BS+BD	Both have fixed starts so are AF has no relationship to BS
4		AF			AF-AD	AF	Now-BD	Now	B is scheduled now regardless of A's finish
5		AF		BF	AF-AD	AF	BF-BD	BF	Both have fixed finishes so are AF has no relationship to BS

Where

• XS is the start of ticket X
• XF is the finish of ticket X
• XD is the duration (estimated effort) of ticket X

and an empty cell is unspecified.

(I think I have all that right. It is, at least, what I intended to code. I'd need to check my test cases to see if I actually test all of that and it actually works.)

I guess my questions to you are 1) are you doing ASAP or ALAP scheduling? 2) Are you in scenario 2 or 3?

I have enabled logscheduling and seeing info in my logfile, and I can pass that along if it helps. ...

[MattLichter]

Wow thanks for the crazy fast and detailed reply. The short answers to your questions: 1) asap 2) none of the above. I am not specifying hours for either task (AD, BD null) and not specifying B start (BS null). Only specifying AS, AF, and BF.

I'm going to digest these charts and see if/where my understanding has failed. Will post back shortly.

[Chris Nelson]

Replying to MattLichter:

Wow thanks for the crazy fast and detailed reply. The short answers to your questions: 1) asap 2) none of the above. I am not specifying hours for either task (AD, BD null) and not specifying B start (BS null). Only specifying AS, AF, and BF.

Are you expecting the schedule to stretch B so that starts at AF and continues to BF? I don't think that'll happen.

I'm going to digest these charts and see if/where my understanding has failed. Will post back shortly.

OK. A screen shot of the chart would help if you still need need feedback.

[MattLichter]

Are you expecting the schedule to stretch B so that starts at AF and continues to BF? I don't think that'll happen.

Yes, since BS and BD are null, I was expecting tracpm to calculate and assign BS to match AF. Instead, what I see is that BS is calculated to match BF. I had assumed that the dependency trumps the hour estimate.

For context, I work on many projects, but only one is managed with Trac. I am really just interested in start and finish dates. Some weeks I may put in 40 hours on the project, other weeks only 5. So duration doesn't extrapolate well to time. The estimated field is still useful for budgetary purposes, so I'll be keeping it. If I unset fields.estimate, the plugin correctly ignores the estimates as desired. However, it still doesn't stretch the start date; BS == BF.

Is the not-stretching behavior a bug or a works-as-intended?

Thanks much,