From: Chris Schlaeger (cs_at_suse.de)
Date: Mon Nov 24 2003 - 21:57:53 CET
From: Chris Schlaeger <cs@suse.de> Date: Mon, 24 Nov 2003 21:57:53 +0100 Message-Id: <200311242157.58114.cs@suse.de> Subject: Re: [taskjuggler] task order is relevant
On Monday 24 November 2003 15:48, Ernst Pfann wrote:
> Hi,
>
> I have seen a (i think) little bit strange behavior of taskjuggler. If i
> try to compile this problem.tjp (see below), there is a error/warning about
> a impossible dependency (with tj-version 1.9.0):
>
> --------------------------------------------------------------------------
> problem.tjp:18: Impossible dependency:
> Task 'research.examine_software' starts at 2003-09-24-14:00:00-CEST but
> needs to follow task research.get_software which has a 'plan' end time of
> 2003-09-30-14:59:59-CEST
> problem.tjp:26: Impossible dependency:
> Task 'research.get_software' ends at 2003-09-30-14:59:59-CEST but needs to
> precede task 'research.examine_software' which has a 'plan' start time of
> 2003-09-24-14:00:00-CEST
> --------------------------------------------------------------------------
>
> But the problem is not what tj means. If i change the order of task
> "maintanance" and task "research", the project compiles without any
> problems and the report matches exactly what i want. It compiles as well if
> i comment in the priority-line in task "maintanance".
>
> The logic seams to be clear: if there is no priority (=500), the order is
> relevant.
>
> The question is: why can't tj resolve this problem.
Because it's not clever enough. ;) Yet.
> Ok - this may be a little tricky. But it should be possible, to get better
> warnings.
That's hard. TaskJuggler has a simple heuristic built into the scheduler that
determines what to do next, whenever there is more than just one option.
Since it cannot look into the future, nore can it reverse decisions made in
the past, this is all it can do. Due to the complexity of the problem that TJ
has to solve, there is no easy answer. To find the optimum solution it would
have to compute all possible scheduling scenarios and then pick the best.
Since the problem is most likely not NP complete, some more clever algorithm
to find the best solution is needed, otherwise bigger projects will quickly
be impossible to schedule. I've this already on my todo, but it will take
some time.
> This was really a problem - because this is just a very small part of our
> tj-plan, automatically build by perl-scripts. And it costs me a lot of time
> to find out, why (the hell) this thing compiles at one time and at another
> time don't.
Using 'priority' can really help TJ to do the job.
Chris
-- KDE 3.1: Conquer your Enterprise Desktop! See http://www.kde.org! GPG Key: 1024D/0500838B A5FE C051 2AFC 9A14 768A 5125 5829 5750 0500 838B
This archive was generated by hypermail 2.1.7 : Mon Nov 24 2003 - 21:58:09 CET