code-centered issue tracking?
Is there anything that allows code-centered issue tracking? Recently, Gustavo Niemeyer had an interesting piece up where he suggests private/protected syntax for Python. His point is that code collaboration doesn’t otherwise work in larger uncontrolled environments of dev groups. I agree with most of his observations but not his conclusion. I’d rather like to see reduced communication costs for changing code. Here is an example of what i mean. If see a code fragment like this:
def somefunc(self, x, y, z):
self._cache = func(x) + other(y)
self.z = self._cache + third(z)
i want to be able to visually mark this code, write a comment like:
hey, i need the third(z) value, and doing self.z-self._cache feels bad – can you help?
and i want my development environment to automatically route this question with exact code refs to the maintainers of the code. This should not take longer than 20 seconds and be automatically managed.
On the receiving side, as the maintainer, i want to get notified and be able to say:
getissues mypkg/subpkg
and have it automatically list me all files and issues for it. So i easily see the above question, do a patch, and issue:
sendpatch PATCHNAME
and type in a message. Maybe automatically CCed to other library maintainers, a mailing list etc. As the original sender i get back a mail and can use a cmdline tool to apply the patch, give feedback and so forth …
IOW, i want to have tools that automatically manage the issue-addressing, code-referencing, finding-out about package info/release numbers, format the comment related to the cited code, send the mail, register an issue automatically and so on. Is there something like this?
If not: doesn’t we already have most of the pieces? What makes sense to use for it? Mercurial and Patch queues? Maybe the new Bitbucket API? Integrate with existing issue tracker? First goal would be to have it manage itself, i guess 🙂
cheers, holger
Written by holger krekel
May 18, 2009 at 11:35 am
Posted in metaprogramming
12 Responses
Subscribe to comments with RSS.
metaprogramming and politics 
I like the idea, especially about the command line tool you describe. And you’re right, the building blocks are already there, and the Bitbucket API would allow you to do this kind of stuff.
In fact, there are already a couple of small scripts that interact with the issue tracker, and adding something like this to it would be a breeze. It’s going to be very interesting to see what kind of workflows people will cook up! 🙂
Jesper Noehr
May 18, 2009 at 11:42 am
And I can offer a hand on some nice-ish graphical interfaces for generic IDE embedding. Am hoping to do some Europython Sprinting on “cool development tools”.
Looks like this feature will need integrating of: Cheeseshop (for meta info/releases/version numbers)
Bitbucket (and launchpad/google code etc etc)
Rope (for code referencing and introspection)
Did I miss anyone.. ?
Ali
May 18, 2009 at 11:58 am
Not exactly what you want perhaps, but this is interesting:
http://www.review-board.org/
I’ve also noticed google code has some form of code review tool that seems to feature some integration with its issue tracker.
As a related topic, it’s often useful to be able to *hack* on a library without having to go find out exactly where in a version control system it is. For that you need version number and associated version control information as well. The ‘mr.developer’ buildout extension offers this interesting feature.
Martijn Faassen
May 18, 2009 at 2:40 pm
Annotea could be a piece in your request – Shared annotation on pages. http://www.w3.org/2001/Annotea/
karl
May 18, 2009 at 8:04 pm
Also, Ditz is somewhat related to this:
http://ditz.rubyforge.org/
“Ditz is a simple, light-weight distributed issue tracker designed to work with distributed version control systems like git, darcs, Mercurial, and Bazaar.”
“Ditz maintains an issue database directory on disk, with files written in a line-based and human-editable format. This directory can be kept under version control, alongside project code. “
Brian Dorsey
May 18, 2009 at 8:23 pm
Trac has support for linking to a file and line number in an issue report, so you can already do this in trac (there is no tool to create an issue from a line on the source code viewer though)
@Brian Dorsey: BugsEverywhere does the same kind of thing and is in python 🙂 the problem with this tie between source and issues is highlighted here http://www.ericsink.com/entries/dbts_fossil.html
@Faassen: I’ve been hearing good praise of mr.project I should probably check it out closely. Maybe box and pip and mr.project might all come together to better the landscape of python deployments, something Holger has not bloged about yet.
Leonardo Santagada
May 19, 2009 at 1:09 am
thanks for all the good links!
@ali let’s definitely do the “cool dev tools sprint”, maybe by spending some time on first showing some already existing ones to each of us 🙂
@faassen thanks for the pointer! I’ll see to try it out with my SoC student. Might be a good fit for the we
b part of things. Mr.developer is also something i’d like to check out.
@karl i see the conceptual relation. Not sure how it could help for doing a primarily command line based tool yet.
@brian i looked at ditz once – and i like the concept of text file issue-tracking. its own issue tracker indicates last activity was 2008-11-01, though.
@leonardo bugseverywhere: there is something that also bugs me with bitbucket: i want to most often track my code-related issues independently from the branches i am working on. IOW, branching the issues doesn’t make sense to me.
@jespern i agree that some building blocks are there but i think that actually handling issues code-centered
might require some changes to issue-tracking logic/APIs. (you haven’t published the Bitbucket API yet, have you?)
So now i wonder what minimal command line tool functionality could be useful already. Looking forward to meeting up at EuroPython 2009 for some hacking sessions!
cheers,
holger
holger krekel
May 19, 2009 at 7:26 am
As said above, code review tools have a lot of overlap in terms of this functionality, although most of them aren’t command-line based. There’s a plugin for Trac that does this (http://trac-hacks.org/wiki/PeerReviewPlugin) but it’s not structured to have maintainers for different areas of code
David Fraser
May 20, 2009 at 7:49 am
Hey Holger,
Thanks for the follow up.
I’ve detailed in a comment in the original post why this doesn’t look like a solution to the exposed problem:
http://blog.labix.org/2009/05/15/class-member-access-control-enforcement-vs-convention/comment-page-1#comment-65659
Gustavo Niemeyer
May 20, 2009 at 10:12 pm
Hey Gustavo,
thanks – i answered in your blog:
http://blog.labix.org/2009/05/15/class-member-access-control-enforcement-vs-convention/comment-page-1#comment-65676
of course it’s also possible to consider both, code-centered issue tracking and having better handling of meant-to-be-private names.
cheers,
holger
holger krekel
May 21, 2009 at 9:29 am
[…] Metaprogramming, Python and testing FTW […]
schlatter.net » Blog Archive » Python Testing
June 22, 2009 at 4:33 pm
Merci pour cette article, un info utile merci ,
jefaismonsite
January 30, 2010 at 2:05 pm