47 Comments »

Filipe Correia said:
Hi Daan. This sounds great. Can’t wait to try the new version!
# 25 December 2008 at 18:40

Filipe Correia said:
Hi! I’d just like to report back that i’ve been using the plugin in a test environment for a few days now, and it’s working really great. I’d say this is the first truly usable version of the plugin. Congrats!
# 6 January 2009 at 14:50

Daan (author) said:
Wow, thanks!
Am already working on the next version
Screenshot:

I you’d like to test, I can send you an egg…
# 6 January 2009 at 15:02

Filipe Correia said:
That chart is looking very good!
Do you have an expected time frame for the new version? I can make some testing if there’s a release candidate that I can try
# 6 January 2009 at 15:23

alex said:
i have a problem while upgrade-ing the trac (i use trac 0.11.2, timingansestimation0.7.5, postgresql 8.0.15, python 2.5)
trac-admin /var/trac/atf upgrade
Traceback (most recent call last):
File “/usr/bin/trac-admin”, line 8, in
load_entry_point(‘Trac==0.11.2′, ‘console_scripts’, ‘trac-admin’)()
File “/usr/lib/python2.5/site-packages/trac/admin/console.py”, line 1294, in run
return admin.onecmd(command)
File “/usr/lib/python2.5/site-packages/trac/admin/console.py”, line 123, in onecmd
rv = cmd.Cmd.onecmd(self, line) or 0
File “/usr/lib/python2.5/cmd.py”, line 219, in onecmd
return func(arg)
File “/usr/lib/python2.5/site-packages/trac/admin/console.py”, line 1139, in do_upgrade
if not self.__env.needs_upgrade():
File “/usr/lib/python2.5/site-packages/trac/env.py”, line 421, in needs_upgrade
if participant.environment_needs_upgrade(db):
File “/usr/lib/python2.5/site-packages/TracBurndown-1.9.1-py2.5.egg/burndown/burndown.py”, line 54, in environment_needs_upgrade
File “/usr/lib/python2.5/site-packages/TracBurndown-1.9.1-py2.5.egg/burndown/dbhelper.py”, line 77, in table_exists
File “/usr/lib/python2.5/site-packages/trac/db/util.py”, line 36, in __getattr__
return getattr(self.cursor, name)
File “/usr/lib/python2.5/site-packages/trac/db/util.py”, line 36, in __getattr__
return getattr(self.cursor, name)
AttributeError: Cursor instance has no attribute ‘connection’
# 12 January 2009 at 18:15

Daan (author) said:
Hi alex,
Did you have a previous version of the burndown plugin? Previous versions are not compatible with PostgreSQL, therefore I’m wondering why you’d get an upgrade error.
- Daan
# 15 January 2009 at 14:20

Daan (author) said:
Hi Filipe,
I do not have an estimated timeframe… I’m currently swamped with work
I need to write an upgrade method, as I changed the format of the Burndown table. Dates are stored now as timestamps instead of ’06/06/08′. This makes it easier to convert to a Python date.
If you have some time on your hands, you may write the upgrade script . Just scan through the table and convert everything. It should be compatible with MySQL, Postgres and SQLite…
- Daan
# 15 January 2009 at 14:23

Filipe Correia said:
Unfortunately, i’ve been having some trouble finding good chunks of free time lately, so i expect i won’t be able to do it
I’ll tell you if meanwhile i do manage to look at it.
# 15 January 2009 at 16:32

alex said:
Hi,
No, this was the first version i’ve tried (1.9.1).
# 15 January 2009 at 17:51

alex said:
Ok, so I’ve tried something else, I installed version 1.9, update the database and upgrade to 1.9.1 and it’s working, so i guess you should check 1.9.1 for fresh postgresql installs, a bug might be there.
Cheers!
# 15 January 2009 at 17:55

alex said:
Sorry for so many comments, I got excited earlier
So now it shows the main page but when I click Start Milestone or Show Burndown Chard I get:
Trac detected an internal error:
AttributeError: Cursor instance has no attribute ‘connection’
Python Traceback
Most recent call last:
File “/usr/lib/python2.5/site-packages/trac/web/main.py”, line 432, in _dispatch_request
File “/usr/lib/python2.5/site-packages/trac/web/main.py”, line 204, in dispatch
File “/usr/lib/python2.5/site-packages/TracBurndown-1.9.1-py2.5.egg/burndown/burndown.py”, line 169, in process_request
File “/usr/lib/python2.5/site-packages/TracBurndown-1.9.1-py2.5.egg/burndown/burndown.py”, line 306, in update_burndown_data
File “/usr/lib/python2.5/site-packages/trac/db/util.py”, line 36, in __getattr__
File “/usr/lib/python2.5/site-packages/trac/db/util.py”, line 36, in __getattr__
# 15 January 2009 at 18:02

Daan (author) said:
Hi alex,
Do you have logging enabled? When I check the source, before row 306 in burndown.py, some logging statements are executed. The output of those statements may be of help….
It looks like there is no open connection…
Which version of the PostgreSQL bindings do you use?
- Daan
# 15 January 2009 at 19:31

Phil said:
I have installed the latest version of the plugin, but I do not see any view of the burndown plugin.
When I installed this version I received
“Database is up to date, no upgrade necessary.”
So from this I have imagined that everything is OK. Equally I can’t seem to find where to assing the appropriate permissions within Trac, so I’m a little confused. I can see the timing and estimation plugin.
any help would be appreciated.
# 19 January 2009 at 06:56

alex said:
It doesn’t show the log output.
So I was saying that I use pyPgSQL 2.4 if that is what you were referring to and i will trim the lines that are already shown:
2009-01-19 10:43:33,181 Trac[burndown] DEBUG:
2009-01-19 10:43:33,181 Trac[burndown] DEBUG: (‘ERROR: null value in column “id” violates not-null constraint\n’,)
2009-01-19 10:43:33,181 Trac[burndown] DEBUG: ERROR: null value in column “id” violates not-null constraint
2009-01-19 10:43:33,181 Trac[chrome] DEBUG: Prepare chrome data for request
2009-01-19 10:43:33,191 Trac[main] ERROR: Cursor instance has no attribute ‘connection’
Traceback (most recent call last):
…
ttributeError: Cursor instance has no attribute ‘connection’
2009-01-19 10:43:33,391 Trac[session] DEBUG: Retrieving session for ID ‘alexandru’
2009-01-19 10:43:33,398 Trac[tande_filters] DEBUG: self.billing_reports= Set([9, 10, 11, 12, 13, 14, 15, 16, 17])
2009-01-19 10:43:33,409 Trac[ticket_webui] DEBUG: TicketWebUiAddon executing
2009-01-19 10:43:33,409 Trac[ticket_webui] DEBUG: TicketWebUiAddon not the correct template
2009-01-19 10:43:33,756 Trac[main] DEBUG: 1703 unreachable objects found.
# 19 January 2009 at 12:09

Daan (author) said:
Hi Alex,
My best guess: The version 1.9 did not have Postgres support. So you have a Postgres burndown table that is not right.
Can you try to drop the burndown table and recreate it with a trac-admin upgrade? Hope this will help… The error ‘null value in column “id”…’ indicates an error in the table format. When you did this, I’m curious to see the log output (to get to the original error).
It is also possible that the old plugin (1.9) is still somhow on the Python path and that the old plugin is called..? Make sure that only one version of the plugin is on the system.
- Daan
# 20 January 2009 at 00:22

nhm tanveer hossain khan (hasan) said:
hi daan,
i have been trying with pgsql now it looks like i broke the whole trac.
can you tell me how i can fix it with pgsql or remove it at least ?
i have installed –
TracBurndown-1.9.1-py2.4.egg
with trac 0.10.5
best wishes,
# 20 January 2009 at 07:01

Alex Dean said:
Hello Daan. Different Alex here (not the same one who posted on ’19 January 2009 at 12:09′). I can go by Alex D. if that helps reduce confusion.
We are starting to use your plugin at my work, and it’s a great help. Thanks very much! I have a question, though, about your implementation of the ‘burndown’ metric.
It seems you use ‘estimated – spent = remaining’, and ‘burndown’ is the same as ‘remaining’. As I understand scrum practices, this is not correct. Burndown is an estimate of hours remaining, but it is not intended to have any direct relationship to the actual number of hours spent. The burndown number goes up or down, but it doesn’t necessarily bear any relationship to the number of hours actually worked. If estimates are perfect, then they are the same, but one essential tenet of scrum is that estimates are inaccurate and need to be refined and changed quite often.
line 288 of burndown.py (in TracBurndown-1.9.1-py2.5.egg) is :
hours += float(estimate) – float(spent)
I believe it should just be:
hours += float(estimate)
This allows the ‘burndown’ (time to completion) value to be completely independent of the ‘hours spent’ value. To record burndown, you would simply modify the ‘estimated’ field. You can still record ‘hours spent’ for billing, etc, but the burndown chart is based only on the ‘estimated’ hours.
I’m interested in what you (and other plugin users) think of this. I realize it’s a big conceptual change. But I also think it’s more in line with scrum best-practices and will help improve the usability of the plugin.
# 24 January 2009 at 01:32

Alex Dean said:
ps : I forgot to add… Thanks very much for your work on this. It is very much appreciated!
# 24 January 2009 at 01:39

Filipe Correia said:
Hi!
Replying to the comment by Alex D., I’ve seen the TimingAndEstimationPlugin being used in two different ways. One is to fill estimated values only once (thus, considering them the “original” estimated values), and to increment the spent time as you add more work to a given ticket (and at the end, it may very well be different than the original estimate, and that’s ok). Another way of using it (and I believe you are taking this one as a premiss) is to keep updating the estimate, as a better estimates can be given as the end of the ticket’s implementation approaches — this way, when the ticket is completely closed, the estimated and the actual spent time will necessarily be the same.
I’m not sure which is the right one… but just to say that the change you are proposing may not make as much sense to other people using these plugins.
Cheers!
# 24 January 2009 at 02:23

Alex Dean said:
Hi Felipe. Yes, I agree with you. Either way works. And I agree that what I’m proposing is a significant change from the current behavior. But I believe that what I’m saying is more in line with the ‘burndown’ concept as described by Ken Schwaber (the co-creator of Scrum).
He talks about burndown vs. time spent on pg. 113-114 of ‘Agile Project Management With Scrum’. (I wish there were an online version I could link to…) He argues that tracking ‘actual vs. estimated hours’ as a metric for improving future estimates only encourages developers to improve their metrics, not to actually produce better code. Accepting that estimates are rough, and subject to change, is a better way forward and encourages developers to focus on the real task, which is writing quality code.
I understand that ‘actual hours’ is pretty important for billing, etc. But for tracking progress toward the completion of sprint goals, he asserts that ‘time to completion’ is the best metric, and I think it’s a persuasive argument.
I wonder if we might make the plugin serve both use cases? Perhaps keep the current behavior as a default, but allow it to be configured to behave as I’m suggesting?
In any case, some additional documentation would be helpful. I’d be willing to help write some if that’s helpful.
# 24 January 2009 at 04:02

Daan (author) said:
Hi Filipe and Alex,
Actually, at my previous company we used it exactly like Alex described. Only the remaining estimated hours were counted. We did not use the Total Hours field, because we didn’t bill hours. For me, the method Alex describes makes more sense. How many hours someone spent is only relevant for billing, or if you want to learn from your previous estimation attempts. So the value in Total Hours can (should) differ from your estimated hours, unless you plan perfectly (never).
I guess making it configurable is the option that makes most sense. Can one of you create a ticket of that on trac-hacks? That way, I will not forget to incorporate these changes.
I currently have little time, in the first week of February I will give a presentation in London about Scala and Wicket. After that presentation I plan to continue work on the next version. We currently use the new version at work, there are some small bugs that need to be fixed before it can be released. Next to that, I have to write the upgrade method and test this extensively
– Daan
# 24 January 2009 at 11:24

Alex Dean said:
Ticket created. http://trac-hacks.org/ticket/4517
# 26 January 2009 at 16:02

Piotr Swiecicki said:
Hi Daan
Great stuff, I love it. I had just one problem with it, as we are using our own ticket statuses, the plugin was not calculating outstanding work properly. I have found this was because of the ticket statuses hardcoded in the code. With the following patch I was able to fix that:
--- burndown/burndown.py        2009-02-17 17:56:21.000000000 +0000
+++ burndown/burndown.py.org    2008-12-20 13:55:06.000000000 +0000
@@ -270,7 +270,7 @@
                                         "    LEFT OUTER JOIN ticket_custom est ON (t.id = est.ticket AND est.name = 'estimatedhours') "\
                                         "    LEFT OUTER JOIN ticket_custom ts ON (t.id = ts.ticket AND ts.name = 'totalhours') "\
                                         "WHERE t.component = %s AND t.milestone = %s"\
-                                        "    AND status NOT IN ('closed') "
+                                        "    AND status IN ('new', 'assigned', 'reopened', 'accepted') "
                     cursor.execute(sqlSelect, [comp['name'], mile['name']])

                     rows = cursor.fetchall()
Does it make sense to include this in the future versions of the plugin?
Kind regards,
# 17 February 2009 at 19:16

Daan (author) said:
Hi Piotr,
Thanks for the patch! Looks like it makes sense to not only check for closed, but what if people are using custom workflows or statuses that have different ‘closed’ or ‘opened’ states?
Currently the plugin assumes that ‘closed’ means: ‘do not calculate this as work’.
That will be changed, assuming that everything should be calculated as work, except this list of ticket statuses.
But what to do when people add a status like ‘For review’. Should tickets in that status be calculated for the Burndown? Maybe statuses should be configurable?
- Daan
# 17 February 2009 at 19:23

Piotr Swiecicki said:
Hi Dan,
Thanks for prompt response. Fully agree, the customizable ticket statues would be perfect.
But, just wonder if the other statuses (like mentioned ‘for review’ for example) should be really ignored. If there is still any outstanding work (for example after review is done developer may need to package the patch), or if there is for example time for review already estimated on the ticket, then it should be still visible on the burndown chart, shouldn’t it? If the work on the ticket is done the total_hours == estimated_hours so it doesn’t harm to take such a ticket into account.
So to conclude it seems to me the only tickets that should be ignored are those in the terminal state – ‘closed’. And probably in most cases this is the only terminal state.
# 17 February 2009 at 19:31

Alex Dean said:
Milestones allow you to configure which status values are considered ‘completed’. Perhaps that might be a good guide here?
http://trac.edgewall.org/wiki/TracIni, in the ‘milestone-groups’ section. Look for the ‘overall_completion’ flag for each group.
# 17 February 2009 at 20:53

Daan (author) said:
That looks interesting…
So the plugin could read from the config file:
[milestone-groups]
closed = closed,for review,ignored
And ignore the ticket statuses ‘closed’, ‘for review’, and ‘ignored’. Everything else is counted for the Burndown. Is this the way to implement it or am I overlooking something?
# 17 February 2009 at 21:54

Phil Crick said:
Does this plugin work with Python 2.3? We’d really like to use the plugin for one of our projects, but we’re stuck on Python 2.3 with very little chance of upgrading until much later in the year.
A 2.3 egg would be very useful too!
thanks
Phil
# 20 February 2009 at 12:50

Daan (author) said:
Hi Phil,
I’ll try to provide a 2.3 egg for the next version. Until then, you can build your own with the sources (see trac-hacks for those)
- Daan
# 20 February 2009 at 22:03

Alex Dean said:
Daan : In the [milestone-config] section, you’d need to look at any group which has an ‘overall_completion’ value of true.
closed.overall_completion = true
in_progress.overall_completion = false
etc…
Note that here ‘closed’ is just an identifier. It doesn’t have any special meaning. It would be possible (but stupid) to configure
closed.overall_completion = false
It is also possible to configure multiple status values without using the milestone configuration. I was just pointing this out as another plugin which has some notion of collecting different status values into ‘complete’ and ‘incomplete’ groups. If you want to do this for the burndown plugin, I think it ought to be in its own configuration, rather than have burndown (or timing & estimation) depend on the config for some other plugin like milestone.
Thoughts?
# 20 February 2009 at 22:14

Olger said:
Hi Daan,
Great plugin, what happened to the capacity line ?
Love using it !!!!
# 27 February 2009 at 15:58

Stuart said:
Hi Daan,
I see from the screenshots that the burndown chart displays hours remaining vs. days of sprint. How are the hours remaining calculated; does the plugin add an estimated hours field to the trac tickets?
We use unit-less ‘story points’ for estimating and planning our agile projects. We have added a ‘Story Points’ field to the trac tickets as a selectable drop down list that uses the Fibonacci number sequence (1, 2, 3, 5, 8, 13, 21, YMBK). Would it be easy for us to modify the burndown chart to display points remaining vs. days of sprint instead?
Best regards,
Stuart
# 2 March 2009 at 15:38

Daan (author) said:
Hi Stuart,
The Burndown plugin checks a field called ‘estimated hours’. You can just put story points in there. I think it’s possible to put your Fibonacci sequence in there by modifying this field so it displays a dropdown instead.
The only thing is that the Burndown still mentions ‘hours’ instead of ‘story points’. Is that a problem?
– Daan
# 2 March 2009 at 16:02

Stuart said:
Hi Daan,
>> The Burndown plugin checks a field called ‘estimated hours’. You >> can just put story points in there.
So could I just modify ‘burndown.py’ and replace all ‘estimated hours’ with ‘story points’?
Would I still have to install the ‘TimingAndEstimationPlugin’?
>> The only thing is that the Burndown still mentions ‘hours’ instead >> of ’story points’. Is that a problem?
No, but could I not change this in the HTML template?
Best regards,
Stuart
# 2 March 2009 at 16:42

Daan (author) said:
Hi Stuart,
If I were you, I would only change the HTML template (burndown.html). That way, upgrades still work with your existing data.
You do not need the TimingAndEstimationPlugin. Simply add this to your Trac configuration (trac.ini):

[ticket-custom]
estimatedhours=text
estimatedhours.value=0
estimatedhours.order=0
estimatedhours.label=Story points

You can the ‘text’ it to your dropdown with cool Fibonacci sequences
# 2 March 2009 at 21:33

Daan (author) said:
By the way, I’m fixing some items for the next version (see screenshot above). This week I will put the release candidate online, which everyone can test. The data format has slightly changed, so I’m busy writing a good upgrade method.
# 2 March 2009 at 21:35

Richard said:
Hi,
Is this likely to work ok with an older Trac 0.10.4? I don’t see any mods between this and 0.10.5 here:
http://trac.edgewall.org/wiki/ChangeLog#a0.10.5
that sound likely to break it?
Thanks very much
Richard
# 15 April 2009 at 13:26

Daan (author) said:
Hi Richard,
It’s untested, but you can try…
- Daan
# 15 April 2009 at 13:32

Richard said:
Ok will do – thanks!
# 15 April 2009 at 13:35

Leandro said:
I’ve installed the plugin, but when I click in the menu’s option Burndown, I get an error: perationalError: no such table: burndown. I’ve not found a script to create the table burndown in the database. Where can I find it?
# 17 April 2009 at 20:42

abhay said:
Hi,
I followed all installation steps as you have mentioned. Trac version is 0.10.4. Running postgres server 8.2.9. I am getting following error
trac-admin /home/techops-tracd/yfroot/webapps/trac/changes upgrade
Command failed: Cursor instance has no attribute ‘connection’
Now whole trac is broken. If there is no quick fix then how do I uninstall the plugin.
Any help is much appreciated. We have lots of data on to our trac.
Thanks,
Abhay
# 15 May 2009 at 03:46

abhay said:
I could able to delete the egg from plugin dir and uncomment two lines from components section. That seems to have brought up trac back to life. While doing that I kept only “timingandestimationplugin.* = enabled” and trac was still broken. So not sure if it was due to burndown or due to timingandestimationplugin.
Would love to try the plugin, any clue what might be going wrong?
-Abhay
# 15 May 2009 at 04:07

Dave said:
Daan,
Is there anywhere I can get hold of the latest source? Trac-hacks only has up to 1.9.1, and I’d like to tinker with the code before building an egg. I don’t see much point in making my modifications based on 1.9.1 if you’re about to change a lot anyway.
Thanks,
Dave.
# 23 May 2009 at 15:59

miscs said:
Hi Daan,
thanks for this superb plugin! Any news on the schedule for the new version you mentioned?
Thanks!
# 10 July 2009 at 10:24

Alessandro said:
Hi,
I’m experiencing the same problem as the first Alex, where there’s a fatal error on upgrading trac (by ‘trac-admin /var/lib/trac/my_project upgrade’) and when I try to open the Burndown menu.
The exception is:
Most recent call last:
* File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/web/main.py”, line 444, in _dispatch_request
Code fragment:
439. try:
440. if not env and env_error:
441. raise HTTPInternalError(env_error)
442. try:
443. dispatcher = RequestDispatcher(env)
444. dispatcher.dispatch(req)
445. except RequestDone:
446. pass
447. resp = req._response or []
448.
449. except HTTPException, e:
Local variables:
Name Value
after [u' except RequestDone:', u' pass', u' resp = ...
before [u' try:', u' if not env and env_error:', u' raise ...
dispatcher
e OperationalError('ERROR: column "started" does not exist\nLINE 1: SELECT ...
env
env_error None
exc_info (, OperationalError('ERROR: column ...
filename '/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/web/main.py'
frames [{'function': '_dispatch_request', 'lines_before': [u' try:', u' ...
has_admin True
line u' dispatcher.dispatch(req)'
lineno 443
message u'OperationalError: ERROR: column "started" does not exist\nLINE 1: ...
req
resp []
tb
tb_hide None
traceback u’Traceback (most recent call last):\n File …
* File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/web/main.py”, line 205, in dispatch
Code fragment:
200. req.args.get(‘__FORM_TOKEN’) != req.form_token:
201. raise HTTPBadRequest(‘Missing or invalid form token. ‘
202. ‘Do you have cookies enabled?’)
203.
204. # Process the request and render the template
205. resp = chosen_handler.process_request(req)
206. if resp:
207. if len(resp) == 2: # Clearsilver
208. chrome.populate_hdf(req)
209. template, content_type = \
210. self._post_process_request(req, *resp)
Local variables:
Name Value
chosen_handler
chrome
err (, OperationalError(‘ERROR: column …
handler
req
self
* File “/usr/lib/python2.5/site-packages/TracBurndown-1.9.1-py2.5.egg/burndown/burndown.py”, line 139, in process_request
Local variables:
Name Value
db
req
self
* File “/usr/lib/python2.5/site-packages/TracBurndown-1.9.1-py2.5.egg/burndown/dbhelper.py”, line 56, in get_milestones
Local variables:
Name Value
cursor
db
* File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/db/util.py”, line 60, in execute
Code fragment:
55. except Exception, e:
56. self.log.debug(‘execute exception: %r’, e)
57. raise
58. if args:
59. return self.cursor.execute(sql_escape_percent(sql), args)
60. return self.cursor.execute(sql)
61.
62. def executemany(self, sql, args=None):
63. if self.log:
64. self.log.debug(‘SQL: %r’, sql)
65. try:
Local variables:
Name Value
args None
self
sql ‘SELECT name, due, completed, started, description FROM milestone order by …
* File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/db/util.py”, line 60, in execute
Code fragment:
55. except Exception, e:
56. self.log.debug(‘execute exception: %r’, e)
57. raise
58. if args:
59. return self.cursor.execute(sql_escape_percent(sql), args)
60. return self.cursor.execute(sql)
61.
62. def executemany(self, sql, args=None):
63. if self.log:
64. self.log.debug(‘SQL: %r’, sql)
65. try:
Local variables:
Name Value
args None
self
sql ‘SELECT name, due, completed, started, description FROM milestone order by …
* File “/usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py”, line 3111, in execute
Code fragment:
3106. self.conn.conn.query(‘ROLLBACK WORK’)
3107. if len(self.conn.notices) != _n:
3108. raise Warning, self.conn.notices.pop()
3109. self.conn.__dict__["inTransaction"] = 0
3110. self.conn._Connection__closeCursors()
3111. raise OperationalError, msg
3112. except InternalError, msg:
3113. # An internal error occured. Try to get to a sane state.
3114. self.conn.__dict__["inTransaction"] = 0
3115. self.conn._Connection__closeCursors_()
3116. self.conn.close()
Local variables:
Name Value
_badQuery False
_n 0
_nl 0
_qstr ‘SELECT name, due, completed, started, description FROM milestone order by …
msg OperationalError(‘ERROR: column “started” does not exist\nLINE 1: SELECT …
parms ()
query ‘SELECT name, due, completed, started, description FROM milestone order by …
self
File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/web/main.py”, line 444, in _dispatch_request
dispatcher.dispatch(req)
File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/web/main.py”, line 205, in dispatch
resp = chosen_handler.process_request(req)
File “/usr/lib/python2.5/site-packages/TracBurndown-1.9.1-py2.5.egg/burndown/burndown.py”, line 139, in process_requestFile “/usr/lib/python2.5/site-packages/TracBurndown-1.9.1-py2.5.egg/burndown/dbhelper.py”, line 56, in get_milestonesFile “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/db/util.py”, line 60, in execute
return self.cursor.execute(sql)
File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/db/util.py”, line 60, in execute
return self.cursor.execute(sql)
File “/usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py”, line 3111, in execute
raise OperationalError, msg
My configuration is:
Trac: 0.11.5
Python: 2.5.2 (r252:60911, Jul 22 2009, 15:52:25)
setuptools: 0.6c8
pyPgSQL: 2.5.1
Genshi: 0.5.1
mod_python: 3.3.1
Subversion: 1.4.6 (r28521)
jQuery: 1.2.6
# 6 August 2009 at 19:06

Alessandro said:
And the traceback on installing:
Traceback (most recent call last):
File “/usr/bin/trac-admin”, line 8, in
load_entry_point(‘Trac==0.11.5′, ‘console_scripts’, ‘trac-admin’)()
File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/admin/console.py”, line 1314, in run
return admin.onecmd(command)
File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/admin/console.py”, line 133, in onecmd
rv = cmd.Cmd.onecmd(self, line) or 0
File “/usr/lib/python2.5/cmd.py”, line 219, in onecmd
return func(arg)
File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/admin/console.py”, line 1149, in do_upgrade
if not self.__env.needs_upgrade():
File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/env.py”, line 429, in needs_upgrade
if participant.environment_needs_upgrade(db):
File “/usr/lib/python2.5/site-packages/TracBurndown-1.9.1-py2.5.egg/burndown/burndown.py”, line 54, in environment_needs_upgrade
File “/usr/lib/python2.5/site-packages/TracBurndown-1.9.1-py2.5.egg/burndown/dbhelper.py”, line 77, in table_exists
File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/db/util.py”, line 38, in __getattr__
return getattr(self.cursor, name)
File “/usr/lib/python2.5/site-packages/Trac-0.11.5-py2.5.egg/trac/db/util.py”, line 38, in __getattr__
return getattr(self.cursor, name)
AttributeError: Cursor instance has no attribute ‘connection’
# 6 August 2009 at 19:09

dima said:
Hi, are any plans for python 2.6? I have upgraded on my linux box this version
Best regards,
# 20 August 2009 at 14:44

Leave your response!

.now reading

jWeekend

jWeekend: Intensive, 1 and 2 day Java Technology, OO, JPA, Spring courses for busy people.