On Fri, Nov 28, 2008 at 04:56:49AM +0000, Lee Baylis wrote: > Hi, > >>>>> I would also like to extend the mrp-resource data schema with a >>>>> 'maximum >>>>> allocatable >>>>> units' field definable on each resource. >> >> What is the definition of this number of units and how does it differ >> from the time that a resource has at a certain moment according to its >> calendar? > > When one assigns a task to a resource in the GUI, a dialog appears offering > the option to assign a number of units (the default presented in the > current release of planner is 100, implying 100% - this is already > configurable by the user). The % should be clarified as bug #387985 suggests. > In the resource usage view, the number of these units assigned at any one > time is added up, and if it goes over 100 (again, implying 100%), then the > resource is classed as overallocated and marked in red. Here, the figure of > 100 was not configurable by the user, but was hard-coded in the > planner-usage-row file. > > The idea, as far as I can tell from reading discussions in bugzilla, is > that people should be able to choose whether or not they actually want > 100(%) to be hard-coded as a maximum. Could you give some links or bug numbers? > Enabling this property on the > resource allows a user to choose some other figure. Once set, usage would > have to go above this new figure before the resource was marked red in the > resource usage view and classed as overallocated. Also, different resources > can be given different limits. > > One example I have been using this for when talking to people is if someone > only works part time, but as you say, you can already get around this by > changing the calendar for the resource. > > However, it is also usable to represent other circumstances - if you know > one resource is more efficient than another, for example. Then resource 1, > an experienced worker, could have a maximum of 100, and resource 2, an > apprentice, could have a maximum of maybe 65. The effort estimate (work) that was entered for the task must already have been made with some efficiency in mind. Why use another level of efficiencies in the scheduling stage? Also setting a fixed efficiency ratio between people will not fit in all situations, because one person could be more efficient at one thing while the other is more efficient at another. > Another scenario may be if you want to allocate with more precision than > 1/100 units - 1/1000, say, or one in a million. In that case we should just increase precision of the existing field. > In any case, I think having something which is configurable with a sensible > default is better than having something which is hard-coded, as is > currently the case. As each feature adds code complexity as well as GUI complexity, I don't agree with new features lightly. I don't want Planner to go the way of MS Project. In my view something which is configurable can well be worse than something that is hard-coded. For me a good feature: - is useful for a large enough number of people - provides functionality that is not yet provided in different but just as fitting ways by existing features - provides more or less complete functionality for that feature As my earlier comments show, it fails at least on number 2 and 3. You may convince me with other use cases though. > I have been working with a #define variable in the mrp-project.h file, > which if set to true turns on overload checking, and false turns it off and > goes back to 'normal'. We can leave it set to false by default in any > further patches I release until we feel it is time to add it to the schema. > The other possibility is having it as a compile-time option, and this might > be worth looking into if it looks like putting through a schema change is > going to take any length of time. Makes sense. Let's keep it a #define for now. Speak up if the old code is becoming too much trouble to keep in working state. > OK, thanks - I have attached revised patches for most of your comments and > a changelog entry. I'll look at them again in the following days and commit them. > Further discussion: > >> The first is that units_in_use is sort of a caching variable. There are >> times when the values stored in them are not up-to-date. Some functions >> have as a precondition that those values are up-to-date, so I would like >> to have them verify that precondition. To enable them to do that, some >> other functions should 'invalidate' that cache somehow. > (...) I agree that keeping a global list of edges is not the way to go. And my comment was merely about units_in_use. I can live with people having to throw away the edges list, but I'd like some assertions that trigger in the following situation: mrp_assignment_edges_insert_sorted_from_assignment() mrp_assignment_edges_plot_units_in_use() mrp_assignment_edges_insert_sorted_from_assignment() mrp_assignment_edges_calculate_max_units_in_use() How about just setting units_in_use to -1 upon creation of the edges and then asserting in mrp_assignment_edges_calculate_max_units_in_use and whereever else units_in_use is accessed. >>> mrp-assignment: >> >> 276: this function is hard to read (because of things like using the >> enum in a subtraction and as a boolean condition). I think it can be >> made more readable and faster at the same time by not splitting out the >> 'common' part of mrp_assignment_edges_remove_to_last_before and >> mrp_assignment_edges_remove_from_first_after. > > Point taken. I have removed it and the enum, and reworked the before and > after functions as you suggested. However, the functions don't quite > perform in the same way as the examples you gave, so they remain a little > more long-winded. Now that they are two separate functions, however, I have > ditched the two g_list_reverses, and used g_list_last instead. Ah, I see. About that, g_list_last needs to traverse the list and I think you can use last = last->prev just before g_list_delete_link, right? I'm not trying to be a nitpick, but somehow I just can't let these cheap optimisations slip by ;-) >> 911: I don't see why mrp_resource_test_if_overallocated() should exist. > This function doesn't just call mrp_resource_allocation_status You're right. Forget I said anything. Regards, Maurice. -- Maurice van der Pot Gentoo Linux Developer griffon26 gentoo org http://www.gentoo.org Gnome Planner Developer griffon26 kfk4ever com http://live.gnome.org/Planner
Attachment:
pgpryb9uwwIcJ.pgp
Description: PGP signature