calendar vs milestones ?

If you create custom fields to hold the start and/or finish dates and configure the plugin to find them (e.g., fields.start, fields.finish), the plugin will parse the dates in those fields and use them to schedule the tickets. Is that clear?

(In [11419]) Add resource leveling to scheduler. Refs #9833, #9042, #9290, #9300, #9691, #9784.

This is rather naive. It makes sure a resource isn't doing two things at once but doesn't yet handle priorities when conflicts occur.

(In [11422]) Add task sorter interface. Refs #9833, #9042, #9290, #9300, #9691, #9784.

(In [11423]) Add simple task sorter. Refs #9833, #9042, #9290, #9300, #9691, #9784.

This sorts by Trac's built-in priority field (after converting the priority strings to integers).

(In [11424]) Implement prioritized scheduling. Refs #9833, #9042, #9290, #9300, #9691, #9784.

This is orthogonal to resource leveling. That is even if resource leveling is disabled, this schedules the tasks for a resource using the configured sorting rule.

(In [11426]) A tree-aware task sorter. Refs #9833, #9042, #9290, #9300, #9691, #9784.

A task's priority depends on its parent's priority.

Includes a base sorter class to hold common sorter methods.

SimpleSorter? and ProjectSorter? derive from the base class.

(Copy effective priority list, just in case.)

Also remove unneeded debugging output. Refs #9648.

(In [11428]) Use calendar and task sorter as enabled in trac.ini. Refs #9290.

Generally, this allows use of web admin to easily enable an implementation.

If none are enabled, this defaults to SimpleCalendar? and SimpleSorter?.

If one is enabled, it is used.

If more than one are enabled, the last one is used and a message is logged. (Note that ExtensionPoint?() returns an unordered list so "last" is rather arbitrary.)

This is a first step toward allowing user-provided calendars.