Strange behaviour when hours remaining are large

[raymond.wooninck@…]

In my TRAC installation I am dealing with sometimes a larger number of remaining hours. I have the following situation :

Developer 1 has 1024 hours remaining Developer 2 has 604 hours remaining Developer 4 has 609.5 houirs remaining If I use the "WorkloadChart(milestone=W2R0.2D, owner=dev1|dev2|dev3, width=600, height=300)" then I see strange results as the remaining hours. The total hours remaining is 933 and it is divided as Developer 1 has 0 hrs left, developer 2 has 440 hrs left and developer 3 has 493 hrs left.

Is this a bug or am I doing something wrong here ?? I have more developers assigned to this milestone, but they should be ignored in the command.

[Joachim Hoessler]

I guess the macro is trying to tell you that the work load of your poor developers is too high :-)

I just figured that for large numbers the slices of the pie aren't sized properly. The numbers at the label however should be calculated correctly. What does the HoursRemaining macro return for that query?

[anonymous]

I agree with you, but the work is planned a number of months upfront. So they have time till next year June to deliver :-)

The HoursRemaining macro delivers a total of 933 hours remaining. This number is also shown on top of the piechart and equals the sum of the amount per developer in the piechart.

So with that both macro's behave equally, but unfortunately wrong.

[Joachim Hoessler]

The calculation itself in both macros is very primitive, so I'm pretty sure that there is nothing wrong. Internally, the macros use the same mechanism as Trac's TicketQuery macro to retrieve the tickets that are included in the calculation. So could you try to use the that macro directly and check if any ticket is missing?

[[TicketQuery(milestone=W2R0.2D, owner=dev1|dev2|dev3,estimatedhours!=None)]]

[anonymous]

I checked the TicketQuery and there are no tickets missing. If I execute your macro's with just one or two developers then everything is shown correctly. I can add a third one if I know that he does not have that much hours remaining. So it seems more a problem of a kind of overflow then incorrect calculation.

I have been checking with adding one developer at the time to the macros and it seems that I can go up to around 2415 hours remaining. After this I can not even add 38 hours. If I add these 38 hours, the total hours suddenly become 1105 hours.

[Joachim Hoessler]

I've tested the macro here with 6 digit numbers without any problems, so I have no idea what could go wrong on your side. Could you add the following debug line to hoursremaining.py, after line 31? That might give us some more hints.

                self.env.log.info("Current estimation: %s\tSum: %s" % (t[self.estimation_field], sum))

[anonymous]

With the help of this log file and also with the newer ticket that was raised, I found the error. It is not really an error, but as you are using the TicketQuery, the result is returned paginated. This means that in a standard installation only the first 100 lines are returned. For the three developers the total tickets goes to 136 matches, which means that the last 36 matches are not counted. I have now set the number of lines per page in the query generally to 200 and now I have a correct count for these three developers.

I guess that you have to find a way to instruct the query to have an unlimited number of lines per page regardless of the general setting in trac.ini. However I am not sure if this is possible to give this as an option to TracQuery.

Thanks for your help.

[Joachim Hoessler]

It should be possible to get all tickets at once by passing max=0 to the query - I'll try to add this by default to all queries.

Closing this ticket as duplicate of #4174