BacklogTypeError: No backlog of type: Sprint Backlog

[admin]

How to Reproduce

While doing a GET operation on /agilo-pro/sprints/demoQLDA/whiteboard, Trac issued an internal error.

(please provide additional details here)

Request parameters:

{'sprint': u'demoQLDA'}

User agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; vi; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16

System Information

Trac	0.12.2
Agilo	1.3.3-pro
Genshi	0.6
pysqlite	2.3.2
Python	2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
setuptools	0.6c9
SQLite	3.3.4
Subversion	1.5.6 (r36142)
jQuery	1.3.2

Enabled Plugins

binary-agilo	1.3.3-pro
tracaccountmanager	0.2.1dev-r5836

Python Traceback

Traceback (most recent call last):
  File "C:\Program Files\Agilo\lib\site-packages\trac-0.12.2-py2.5-win32.egg\trac\web\main.py", line 511, in _dispatch_request
    dispatcher.dispatch(req)
  File "C:\Program Files\Agilo\lib\site-packages\trac-0.12.2-py2.5-win32.egg\trac\web\main.py", line 237, in dispatch
    resp = chosen_handler.process_request(req)
  File "z:\code\projekte\agile42\stuff\windows_installer\agilo installer\agilo\lib\site-packages\binary_agilo-1.3.3_PRO-py2.5.egg\agilo\api\view.py", line 155, in process_request
  File "z:\code\projekte\agile42\stuff\windows_installer\agilo installer\agilo\lib\site-packages\binary_agilo-1.3.3_PRO-py2.5.egg\agilo\api\view.py", line 143, in _call_filters_and_handler
  File "build/bdist.macosx-10.6-i386/egg/agilo_pro/web_ui.py", line 138, in do_get
  File "build/bdist.macosx-10.6-i386/egg/agilo_pro/web_ui.py", line 78, in _get_backlog_info
  File "z:\code\projekte\agile42\stuff\windows_installer\agilo installer\agilo\lib\site-packages\binary_agilo-1.3.3_PRO-py2.5.egg\agilo\scrum\backlog\json_ui.py", line 110, in backlog_info
  File "z:\code\projekte\agile42\stuff\windows_installer\agilo installer\agilo\lib\site-packages\binary_agilo-1.3.3_PRO-py2.5.egg\agilo\scrum\backlog\json_ui.py", line 49, in _get_backlog
  File "z:\code\projekte\agile42\stuff\windows_installer\agilo installer\agilo\lib\site-packages\binary_agilo-1.3.3_PRO-py2.5.egg\agilo\api\controller.py", line 361, in process_command
  File "z:\code\projekte\agile42\stuff\windows_installer\agilo installer\agilo\lib\site-packages\binary_agilo-1.3.3_PRO-py2.5.egg\agilo\api\controller.py", line 315, in execute
  File "z:\code\projekte\agile42\stuff\windows_installer\agilo installer\agilo\lib\site-packages\binary_agilo-1.3.3_PRO-py2.5.egg\agilo\scrum\backlog\controller.py", line 56, in _execute
  File "z:\code\projekte\agile42\stuff\windows_installer\agilo installer\agilo\lib\site-packages\binary_agilo-1.3.3_PRO-py2.5.egg\agilo\scrum\backlog\model.py", line 571, in get
  File "z:\code\projekte\agile42\stuff\windows_installer\agilo installer\agilo\lib\site-packages\binary_agilo-1.3.3_PRO-py2.5.egg\agilo\core\model.py", line 1128, in get
  File "z:\code\projekte\agile42\stuff\windows_installer\agilo installer\agilo\lib\site-packages\binary_agilo-1.3.3_PRO-py2.5.egg\agilo\scrum\backlog\model.py", line 168, in __init__
BacklogTypeError: No backlog of type: Sprint Backlog

[Remy Blank]

PluginIssue (AgiloForScrum).

[robert.buchholz@…]

@rblank: thanks for the CC. I'm always surprised we have no users posting bugs here for weeks and then three in a row…

@admin/reporter: Please visit the Agilo Google Group to continue debugging this problem. It looks like you removed the Sprint Backlog, which breaks an assumption of the whiteboard.

[Remy Blank]

Replying to robert.buchholz@…:

I'm always surprised we have no users posting bugs here for weeks and then three in a row…

Our semi-automatic bug reporting could be improved. For plugins hosted on trac-hacks, if we detect that a source file from the plugin appears in the traceback, the bug report goes to trac-hacks (provided that the plugin's home_page refers trac-hacks). This unfortunately doesn't work (yet) with plugins hosted elsewhere, as we can't assume that the home_page is a Trac instance. We should find a way for plugins to specify a Trac instance to report errors.

[Christian Boos]

Hehe, I thought about the same ;-)

Replying to robert.buchholz@…:

@rblank: thanks for the CC. I'm always surprised we have no users posting bugs here for weeks and then three in a row…

I'm actually surprised we still have semi-automated bug reports for recent versions of Agilo ;-)

IIUC, you only have plugins and don't patch Trac itself, which makes it a bit difficult to change the address of the BTS. What about the following change:

trac/web/main.py

@@ -53 +53 @@
 from trac.web.href import Href
 from trac.web.session import Session
 
+# The following URL is used for semi-automatic bug reports.
+# Please modify if you ship a customized version of Trac.
+tracker = 'http://trac.edgewall.org'
 
 class FakeSession(dict):
     sid = None
@@ -571 +574 @@
     traceback = get_last_traceback()
 
     frames, plugins, faulty_plugins = [], [], []
-    tracker = 'http://trac.edgewall.org'
     th = 'http://trac-hacks.org'
     has_admin = False
     try:

And then you could do: trac.web.main.tracker = 'http://dev.agile42.com' for example.

[Christian Boos]

Replying to rblank:

… we can't assume that the home_page is a Trac instance. We should find a way for plugins to specify a Trac instance to report errors.

We already support the trac entry for that, but it's not advertised in the various plugin cooking tutorials.

[Remy Blank]

Replying to cboos:

We already support the trac entry for that, but it's not advertised in the various plugin cooking tutorials.

Right, I missed that. Then we should advertise it! So I assume the change in comment:4 isn't needed? And the property should be set in the Agilo plugin ASAP :)

[Christian Boos]

Replying to rblank:

So I assume the change in comment:4 isn't needed?

No, unless the Agilo people would like to get the default bug reports from their users.

I just checked, and there are only very few tickets that would be concerned (the recent #10030 probably made me think otherwise), the vast majority of the Agilo related tickets do indeed have some Agilo plugins in the reported backtrace.

The patch might still be worthy in the longer term, if one day someone distributes a forked version of Trac, to make that hard-coded URL more noticeable.

[robert.buchholz@…]

We already track that as a bug in Agilo at ​https://dev.agile42.com/ticket/1105

I'll see if we can squeeze a fix into the next release.

[Christian Boos]

See also r10701 (I can't register/login on dev.agile42.com, it seems).

[Remy Blank]

Why use a "docstring" (not really one, actually) instead of a normal comment in [10701]?

[Christian Boos]

Replying to rblank:

Why use a "docstring" (not really one, actually) instead of a normal comment in [10701]?

It is a docstring … for Sphinx. See [10704] and the corresponding ​ApiDoc:api/trac_web_main#miscellaneous.

[Remy Blank]

Oh, so it is a docstring after all. Unfortunately, it triggers a "String statement has no effect" warning in pylint. Could we instead standardize on using the #: comment form?

trac/web/main.py

@@ -53 +53 @@
 from trac.web.href import Href
 from trac.web.session import Session
 
+#: This URL is used for semi-automatic bug reports (see
+#: `send_internal_error`).  Please modify it to point to your own
+#: Trac instance if you distribute a patched version of Trac.
 default_tracker = 'http://trac.edgewall.org'
-"""This URL is used for semi-automatic bug reports (see
-   `send_internal_error`).  Please modify it to point to your own
-   Trac instance if you distribute a patched version of Trac.
-"""
+
 
 class FakeSession(dict):
     sid = None

[Christian Boos]

Well, I picked """…""" instead of #: precisely because this looks like a docstring and not yet another convention to remember. OTOH, this #: convention seems also widespread (epydoc had it as well) and as it plays better with other tools like pylint, I'm fine with adopting that convention.

Another possibility would be to disable that specific warning until they take this specific case into account (​http://www.logilab.org/ticket/9848).

Btw, if you have a standard way to run pylint, maybe I could integrate that in the Makefile (make pylint)?

[Remy Blank]

Replying to cboos:

Another possibility would be to disable that specific warning until they take this specific case into account (​http://www.logilab.org/ticket/9848).

Yes, I know, I already have about 20 exceptions. In this case, the comment makes more sense to me, because the "docstring" really is dead code and cannot be retrieved dynamically (unlike real docstrings).

Btw, if you have a standard way to run pylint, maybe I could integrate that in the Makefile (make pylint)?

I run it through Eclipse, but I'll test it on the command-line and set the options so that only meaningful warnings are shown. There are a few errors, too, mainly "possibly undefined local variables" due to locals being set in a loop.

[Christian Boos]

Replying to rblank:

… In this case, the comment makes more sense to me, because the "docstring" really is dead code and cannot be retrieved dynamically (unlike real docstrings).

Patch from comment:12 committed in r10707.

… I'll test it on the command-line and set the options so that only meaningful warnings are shown.

Feel free to send it directly to me once you have it!

[Remy Blank]

I have added the pylint make target in [10708], but unfortunately my pylint crashes during the run. And there are still many unnecessary warnings (e.g. line lengths in test files), so some fine-tuning will be in order. But at least we have a basis.

[Christian Boos]

Replying to rblank:

I have added the pylint make target in [10708], but unfortunately my pylint crashes during the run.

I've found ​http://www.logilab.org/ticket/37105 and added a backtrace there.

And there are still many unnecessary warnings (e.g. line lengths in test files), so some fine-tuning will be in order. But at least we have a basis.

Yes, thanks!