Re: cmd manager transactions



Maurice van der Pot wrote on 25/12/8 at 10:47:
I sent some comments on the patch earlier.
I don't think I ever got these comments, and they're not in the planner-dev-list archives. Sorry to be a pain, I don't suppose you have copy-to-self?

I have also noticed some
indentation inconsistencies in the patches. Do you have your indentation
set to tabs? vim & emacs should be able to use the mode lines at the
top.
I'm using emacs and the mode lines seem to be working OK -- I realised there might have been some indentation inconsistencies in the middle of lines (in order to pull arguments for functions in line, for example) because of some late changes I made, but I thought indents at the beginning of lines should have all been fine. I will keep an eye on it in future patches.

If you could also send the changes to multiple files in one patch,
that would be easier for me.
OK. I am currently moving all my patches from svn to git to make sure nothing has changed meanwhile, but when done I will send a single file.
I was wondering, how do you plan to proceed from the
overallocation-prohibited version? What kind of user interaction with
the GUI would we eventually have?

The next step I took is to have a simple algorithm which fires when an overallocation is detected, and alters the allocations which clash based on task priority, in order to bring allocation to max_units. At the moment none of it is settable in the GUI and it is only done at compile time.

However, I envisage eventually having a property settable on the project so that a user can pick which algorithm they want for the entire project when overallocation occurs. Options might be

- ignore (planner's current behaviour)

- prohibit (as per my first proof of concept)

- reallocate conflicts based on priority (as per my second proof of concept)

- reschedule conflicts based on priority (I don't have the code for this yet but I have a good idea how the algorithm would work)

- other algorithms (libRCPS maybe)

- Ask me every time (produces a dialog with the options above when overallocation occurs)
Now I was thinking on how to handle integration of your (future) changes
into planner. There are disadvantages to each approach I can come up
with:

committing to trunk:
- if it takes a long time to finish, it could be in the way for
  in-between releases
- I wouldn't like to litter the code with ifdefs, especially in cases
  where you would rewrite large pieces of old code

committing to a branch:
- subversion < 1.5 doesn't have merge tracking. I haven't been able to
  figure out if Gnome's running 1.5 yet.

distributed version control:
- Gnome doesn't offer it
- I've never worked with it (though I've always wanted to try Git) =)

Looks like moving to git has got around this problem (or will have when I migrate my existing patches)

Thanks,
lee
Regards,
Maurice.

------------------------------------------------------------------------

_______________________________________________
Planner-dev-list mailing list
Planner-dev-list gnome org
http://mail.gnome.org/mailman/listinfo/planner-dev-list


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]