Re: [Planner Dev] One step behind, two steps ahead.
- From: Matteo Nastasi <nastasi alternativeoutput it>
- To: planner-dev lists imendio com
- Subject: Re: [Planner Dev] One step behind, two steps ahead.
- Date: Tue, 20 Jun 2006 07:37:03 +0200
On Mon, Jun 19, 2006 at 07:49:50PM -0400, Kurt Maute wrote:
> On Mon, 2006-06-19 at 10:07 +0200, Matteo Nastasi wrote:
> > Hi, I would share my thoughts about the possible evolutions of planner
> > with you and get your feedbacks.
> >
> > Two steps ahead:
> > 1) I would to see full_priority_scheduling work fine in planner.
>
> Great! So would I!
>
> > 2) When a 1) will be reality I wouldn't see an application
> > that it cannot be used in the real world; a simple example that
> > troubles me:
> > - 2 tasks ("A" and "B")
> > - they start at the same time
> > - they use the same resources
> > - "A" priority > "B" priority
> > - they are long 2 weeks-work
> > For one week task "A" go ahead to 50% and task "B" remains to 0%.
> >
> > After 1 week some reason imposes to change "B" priority > "A" priority;
> > what will happen?
> >
> > In my mind I suppose that the task "A" remains to 50% and task "B",
> > starting from the 2' week, begin to grow.
> > To implement my view planner needs a data model enhancement that
> > allow:
> > - correlation between "present time" and priority modifications
> > - to store each priority modification and it's time and/or made
> > work before it for each task.
>
> I think in order to do this, we need to implement the ability to
> baseline the project: http://bugzilla.gnome.org/show_bug.cgi?id=140676
>
> That's the only way we could be sure to capture a snapshot of the tasks
> such that any changes, whether they're to priority or which resource is
> allocated, or whatever, the history remains untouched.
I want to study the multi-baseline solution to find implications,
advantages and so on ...
> > One step behind:
> > 1) to develope the previously described features in an acceptable time,
> > at least for the first devel iteration, we must inactivate all kinds
> > of task's dependencies that imply retroactions (Kurt, don't hates
> > me ;), because the interaction between retroactions and
> > full_priority_scheduling enhances algorithms complexity very much.
>
> Could you clarify what you mean by retroactions? You mean maybe tasks
> that calculate start date from the end date like FF & SF?
Yes, the worst example is a snake chain of tasks like FS, FF, FS, FF ...
with overlapping resources ;); leveling this configuration isn't
simple.
> Kurt Maute <kurt maute us>
Regards, Matteo.
--
Matteo Nastasi - Milano - Italy | HomePage: www.alternativeoutput.it
Sostenere e supportare GNU/Linux ! | IRC: #linux-mi irc freenode net
Milano Linux | E-Mail: matteo nastasi milug org
Users Group www.milug.org | nastasi alternativeoutput it
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]