Re: [Planner Dev] One step behind, two steps ahead.

[Matteo Nastasi <nastasi alternativeoutput it>]

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