Menu
▾
▴
pyblosxom-devel
|
From: will kahn-g. <wi...@bl...> - 2010-09-30 19:14:59
|
We've switched from svn to git. That solved a bunch of problems. Yay! We've moved the website from Sourceforge to Bluesock (my server) and that's solved some problems and has the potential to solve more problems. Yay! The next two problems to solve are these: 1. issue tracking 2. plugin/flavour registry I really want to solve number 1 next. An issue is a bug, feature, plugin idea, documentation suggestion, ... I want to use an issue tracking system that is: 1. maximizes ease of use 2. minimizes spam 3. maximizes ability of anonymous people to use -- people shouldn't have to create an account to log a bug (maybe this is solved by people sending me email--I don't know) 4. maximizes the ability to figure out where PyBlosxom is at in terms of issues, items that should be done, things that people can jump in and work on, ... 5. minimizes administration, maintenance and installation difficulties 6. must be Free Software To reduce the scope of this conversation, I offer the following anti-suggestions: 1. no bugzilla -- it's great, I love it, doesn't meet my requirements for PyBlosxom 2. no Trac -- other people like it, I don't What options are there out there? Should we go for a git-based distributed issue tracking system? Should we roll our own system using the PyBlosxom core? Are there other requirements I'm not thinking about? I'd love to talk about this for the next couple of weeks and come to some kind of solution both for the software to use as well as any workflow suggestions that address the requirements. Then we'll implement something in late October and solve this problem because it's seriously hampering our mojo and that sux0rz. /will |
|
From: Tim G. <tg...@pr...> - 2010-10-01 02:55:32
|
On Sep 30, 2010 at 03:14 PM -0400, will kahn-greene wrote: I've never really developed anything (haha) so take my suggestions with a grain of salt. Of the couple issue tracking systems I've encountered, trac and google code's system both seemed easily understandable to the outsider. It's very easy to get a sense of what the latest progress is. I understand you don't want to use trac though. > What options are there out there? ikiwiki could be interesting. It's based off of a revision control system, so that's a big plus. It can be hosted in git, so it could live right along side the source code. Or in a separate repository. Which would also make it distributed. It has bug tracking, todos, etc. built in. It also appears to allow for anonymous bug submissions. Looks like a cool project to me. Google code has a nice clean interface too. I don't know how easy/hard it would be to glue it onto a project hosted elsewhere though. > Should we go for a git-based distributed issue tracking system? See above. > Should we roll our own system using the PyBlosxom core? A possibility, but I might say the time and effort spent implementing an issue tracking system could be better spent elsewhere. On a separate note, I'd like to contribute more to pyblosxom development (when I get a bit of time). I've hacked up a number of plugins already just in the last couple weeks of usage, but I'd like to help in a more meaningful way as well. |
|
From: Sebastian S. <Seb...@SS...> - 2010-10-01 06:54:19
|
On 2010-09-30, will kahn-greene wrote: > We've switched from svn to git. That solved a bunch of problems. Yay! Yay! > We've moved the website from Sourceforge to Bluesock (my server) and > that's solved some problems and has the potential to solve more > problems. Yay! Even more yay! > 1. issue tracking I have used roundup which is written in python and used by python.org. It seems decent and has an email interface, so you can log issues just by sending an email. (a cron script polling a mailbox, so you could run a spamfilter before) It is pretty ok, I think. No spam filter built into it though. As for distributed git-based stuff, here is a list http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/ Of these, these 2 seem most interesting to me: http://bugseverywhere.org/be/show/HomePage http://syncwith.us/sd/ Otherwise, there are hosted things such as: http://lighthouseapp.com/ which provide free issue tracking, but that one requires an account with them. > Should we roll our own system using the PyBlosxom core? Hehe, a bugtracking plugin for pyblosxom? Sounds like a cool idea. Especiall http://bugseverywhere.org/be/show/HomePage (bugs in git alongside the source code) which is written in python could proabably be adapted to have a pyblosxom interface, their current webfrontent is using web.py and some templates. it seems. have never used it though. Sebastian |
|
From: Marius G. <ma...@ge...> - 2010-10-01 12:48:36
|
On Thu, Sep 30, 2010 at 03:14:50PM -0400, will kahn-greene wrote: > I really want to solve number 1 next. An issue is a bug, feature, > plugin idea, documentation suggestion, ... I want to use an issue > tracking system that is: > > 1. maximizes ease of use > > 2. minimizes spam > > 3. maximizes ability of anonymous people to use -- people shouldn't have > to create an account to log a bug (maybe this is solved by people > sending me email--I don't know) > > 4. maximizes the ability to figure out where PyBlosxom is at in terms of > issues, items that should be done, things that people can jump in and > work on, ... > > 5. minimizes administration, maintenance and installation difficulties > > 6. must be Free Software 1, 2 and 5 are best solved by using a hosted bug tracker (Launchpad.net, Google Code, Github, Bitbucket). Most of them will fail 3 and 6. 3 and 2 are difficult to combine. I get the wive that you want to host the issue tracker yourself, which will require great effort for 2, and nontrivial effort for 5. > To reduce the scope of this conversation, I offer the following > anti-suggestions: > > 1. no bugzilla -- it's great, I love it, doesn't meet my requirements > for PyBlosxom > > 2. no Trac -- other people like it, I don't > > What options are there out there? Roundup. Worse than Trac, in my opinion. Could be made to work, perhaps, with enough effort. I've no direct experience with other issue trackers. > Should we go for a git-based distributed issue tracking system? > > Should we roll our own system using the PyBlosxom core? As a user I'd be happier to see efforts going into improving PyBlosxom's core, plugins, and especially integration (a better out-of-the-box experience with more features), than into inventing a yet another issue tracker. But if you find it interesting/fun, go for it! > Are there other requirements I'm not thinking about? > > I'd love to talk about this for the next couple of weeks and come to > some kind of solution both for the software to use as well as any > workflow suggestions that address the requirements. Then we'll > implement something in late October and solve this problem because it's > seriously hampering our mojo and that sux0rz. Why not use a hosted solution in the interim? Pick one that lets you export all your data easily, so you can migrate to a self-hosted tracker later. Personally, I like the Launchpad bug tracker. Well, "like" is not the right word -- it's pedestrian, doesn't invoke feelings of love, but it gets the job done with minimum effort from my side, which I appreciate. Marius Gedminas -- Never trust a computer you can't repair yourself. |
|
From: Asheesh L. <as...@as...> - 2010-10-02 00:37:20
|
On Thu, 30 Sep 2010, will kahn-greene wrote:
> I really want to solve number 1 next. An issue is a bug, feature,
> plugin idea, documentation suggestion, ... I want to use an issue
> tracking system that is:
>
> 1. maximizes ease of use
>
> 2. minimizes spam
>
> 3. maximizes ability of anonymous people to use -- people shouldn't have
> to create an account to log a bug (maybe this is solved by people
> sending me email--I don't know)
2 and 3 are tough together.
I would try Roundup...
> 4. maximizes the ability to figure out where PyBlosxom is at in terms of
> issues, items that should be done, things that people can jump in and
> work on, ...
You can do that with custom queries (if you pay attention to making a
query) in most bug trackers except Launchpad's :P
> 5. minimizes administration, maintenance and installation difficulties
>
> 6. must be Free Software
*nod*
self-hosted Roundup is slightly less attractive for you, but on the other
hand Roundup has a pretty high quality Debian package.
> What options are there out there?
>
> Should we go for a git-based distributed issue tracking system?
Eek, they all have really low usability as far as I know.
> Should we roll our own system using the PyBlosxom core?
Heck no. :P
> Are there other requirements I'm not thinking about?
Email interaction? Roundup has that, for what it's worth.
-- Asheesh.
--
<_Anarchy_> acf: maybe April 1 next year slashdot needs to run "Rob Malda
accepts new job as head of Debian project" 8)
|
|
From: Blake W. <bw...@la...> - 2010-10-04 21:11:53
Attachments:
smime.p7s
|
On 10-09-30 3:14 PM, will kahn-greene wrote: > We've switched from svn to git. That solved a bunch of problems. Yay! > 1. issue tracking > > I really want to solve number 1 next. An issue is a bug, feature, > plugin idea, documentation suggestion, ... I want to use an issue > tracking system that is: So, why not use GitHub's issue tracker? > 6. must be Free Software Well, that's a reason, but if you're not installing the tracker, does it still have to be Free? Later, Blake. |
|
From: will kahn-g. <wi...@bl...> - 2010-10-04 21:40:25
|
On 10/04/2010 05:11 PM, Blake Winton wrote: > On 10-09-30 3:14 PM, will kahn-greene wrote: >> We've switched from svn to git. That solved a bunch of problems. Yay! >> 1. issue tracking >> >> I really want to solve number 1 next. An issue is a bug, feature, >> plugin idea, documentation suggestion, ... I want to use an issue >> tracking system that is: > > So, why not use GitHub's issue tracker? We're not using Github--we're using Gitorious. I kind of like Gitorious and I don't want to switch unless there's a very compelling reason to do so. >> 6. must be Free Software > > Well, that's a reason, but if you're not installing the tracker, does it > still have to be Free? We're switching off of SourceForge because it was a total pain in the ass. I'd rather not use another hosted solution that I have no control over unless there's a very compelling reason to do so. I'd rather spend my time writing my own system or enhancing an existing one. /will |
|
From: will kahn-g. <wi...@bl...> - 2010-10-04 22:50:02
|
On 10/04/2010 05:55 PM, Blake Winton wrote: > > So, I've been working on a project called Basie > <http://basieproject.org/> which would be perfect for what you're trying > to do, except it's not really production quality. The direction Basie > is now taking is to extract out the useful bits, and make them available > to plug into Django as Pinax <http://github.com/pinax/pinax/> apps. > Fortunately, there's already a Pinax app for issue tracking > <http://github.com/pinax/pinax/tree/master/pinax/apps/tasks/>, and the > Basie project has contributed a VCS-browser. Sadly, the VCS-browser > only supports svn and hg for now > <http://bitbucket.org/basie/vcsbrowser/src/tip/apps/vcsbrowser/backends/>, > but adding git support shouldn't be too hard. (It was mainly licensing > issues which were preventing it, afair.) That looks awesome! I was wondering what happened to Dr Project. I'll definitely take a look at it. I was just working on a project called WSGit that provides a web-view for a git repository: http://gitorious.org/wsgit I could probably use that knowledge to finagle git support, though I'd probably use dulwich [1]_ rather than git-python [2]_ since git-python is in pretty serious flux. .. [1]: http://samba.org/~jelmer/dulwich/ .. [2]: http://gitorious.org/git-python Anyhow, I'll take a look at it next week. /will |
|
From: Dieter P. <di...@pl...> - 2010-10-05 07:19:45
|
There's also redmine (http://www.redmine.org/), I guess it's like Basie (but production quality and supports git), but written in RoR instead of python/django. my buddy who runs http://www.luakit.org is very happy with it. Dieter |
|
From: Blake W. <bw...@la...> - 2010-10-04 21:55:29
Attachments:
smime.p7s
|
On 10-10-04 5:40 PM, will kahn-greene wrote: >>> We've switched from svn to git. That solved a bunch of problems. Yay! >>> 1. issue tracking >> So, why not use GitHub's issue tracker? > We're not using Github--we're using Gitorious. I kind of like Gitorious > and I don't want to switch unless there's a very compelling reason to do so. That makes a lot of sense. (When you said you switched to git, I figured you must be using GitHub. ;) >>> 6. must be Free Software >> Well, that's a reason, but if you're not installing the tracker, does it >> still have to be Free? > We're switching off of SourceForge because it was a total pain in the > ass. I'd rather not use another hosted solution that I have no control > over unless there's a very compelling reason to do so. > > I'd rather spend my time writing my own system or enhancing an existing one. So, I've been working on a project called Basie <http://basieproject.org/> which would be perfect for what you're trying to do, except it's not really production quality. The direction Basie is now taking is to extract out the useful bits, and make them available to plug into Django as Pinax <http://github.com/pinax/pinax/> apps. Fortunately, there's already a Pinax app for issue tracking <http://github.com/pinax/pinax/tree/master/pinax/apps/tasks/>, and the Basie project has contributed a VCS-browser. Sadly, the VCS-browser only supports svn and hg for now <http://bitbucket.org/basie/vcsbrowser/src/tip/apps/vcsbrowser/backends/>, but adding git support shouldn't be too hard. (It was mainly licensing issues which were preventing it, afair.) Later, Blake. |
|
From: seanh <sn...@gm...> - 2010-10-05 12:24:24
|
Does gitorious plan to implement a bug tracker like github has? What bug trackers do other projects on gitorious use? I notice that for the gitorious source code (which is hosted on gitorious) they use Lighthouse, which I don't think is free software. I looked at some of the featured projects on the gitorious front page to see what they use. StatusNet hosts its own bug tracker at its website: http://status.net/open-source/issues I guess that is a drupal module? XBMC hosts its own trac. OpenSuSe uses Bugzilla. Qt uses some enterprise thing. None of these feel very pyblosxom. I'd say Lighthouse, because it claims to be very simple, seems most appropriate but it isn't free software. I suggested using Launchpad back when we were thinking about moving from Sourceforge. I've seen projects before that use Launchpad for some things (e.g. issue tracking) and another site for other things (e.g. code hosting). I think we could go with that still. We'd use gitorious for the code hosting, bluesock for the website, we already seem to have mailing lists, but Launchpad could provide us with (whichever we want from): bug tracking, translations, Ubuntu package building and hosting (we could have a PyBlosxom PPA), blueprint and specification tracking, and the community support thingy "Launchpad Answers". The disadvantage is that Launchpad is quite a confusing and difficult-to-navigate site, and that we'd be spreading things across even more services (bluesock, gitorious, sourceforge, launchpad), although we could use the front page of the bluesock pyblosxom website as the central place to link to them all. It might have the potential for things to get quite confusing. |
|
From: Dieter P. <di...@pl...> - 2010-10-05 12:33:24
|
On Tue, 5 Oct 2010 12:24:14 +0000 seanh <sn...@gm...> wrote: > Does gitorious plan to implement a bug tracker like github has? > > What bug trackers do other projects on gitorious use? > > I notice that for the gitorious source code (which is hosted on > gitorious) they use Lighthouse, which I don't think is free software. > > I looked at some of the featured projects on the gitorious front page > to see what they use. StatusNet hosts its own bug tracker at its > website: > > http://status.net/open-source/issues > > I guess that is a drupal module? > > XBMC hosts its own trac. > > OpenSuSe uses Bugzilla. Qt uses some enterprise thing. > > None of these feel very pyblosxom. I'd say Lighthouse, because it > claims to be very simple, seems most appropriate but it isn't free > software. > > I suggested using Launchpad back when we were thinking about moving > from Sourceforge. I've seen projects before that use Launchpad for > some things (e.g. issue tracking) and another site for other things > (e.g. code hosting). I think we could go with that still. We'd use > gitorious for the code hosting, bluesock for the website, we already > seem to have mailing lists, but Launchpad could provide us with > (whichever we want from): bug tracking, translations, Ubuntu package > building and hosting (we could have a PyBlosxom PPA), blueprint and > specification tracking, and the community support thingy "Launchpad > Answers". The disadvantage is that Launchpad is quite a confusing and > difficult-to-navigate site, and that we'd be spreading things across > even more services (bluesock, gitorious, sourceforge, launchpad), > although we could use the front page of the bluesock pyblosxom > website as the central place to link to them all. It might have the > potential for things to get quite confusing. Launchpad is IMHO hard-to-work-with bloatware. We can also use bugseverywhere. It's a distributed bugtracker that stores issues in your git repo, next to the code. http://bugseverywhere.org/be/show/HomePage I thisk distributed bugtracking in general makes a lot of sense (read the bugseverywhere page and/or http://lwn.net/Articles/281849/) I've never tried bugseverywhere myself though, they say they have a webinterface for people who don't like the commandline, but not sure how well that works. Dieter |
|
From: Tim G. <tg...@pr...> - 2010-10-05 13:37:34
|
On Oct 05, 2010 at 12:24 PM +0000, seanh wrote: > The disadvantage is that Launchpad is quite a confusing and > difficult-to-navigate site, and that we'd be spreading things across even > more services (bluesock, gitorious, sourceforge, launchpad), although we > could use the front page of the bluesock pyblosxom website as the central > place to link to them all. It might have the potential for things to get > quite confusing. I've been thinking about this, and though I don't have any more specific suggestions, I think this is a good point. If it were me, I'd either consolidate the source code, web page, and bug tracking on an external service, or try to keep them all in house. Though having the source on gitorious isn't the end of the world - anybody who wants a the current dev version should know enough to navigate multiple sites. But, if you want the issue tracking to be visible and easily useable by first timers, then I think it might be a good idea if it is well integrated into bluesock. I guess that doesn't necessarily mean it should be hosted at bluesock, but I think I would stay away from using just the issue tracking part of a larger integrated service. Furthermore, a nice clean activity and roadmap interface really helps to answer Will's original point 4 about status visibility. Trac and Redmine seem relatively intuitive in this way to me. Since Will doesn't like Trac, I think Redmine looks good to me. One thing I've been keeping in mind as I look at the different suggestions is whether or not the mentioned package hosts their own package's project page via their package's web interface. I figure any modern issue tracker should have the ability to have an overview page and some kind of wiki like thing for each project (which should be sufficient for an issue trackers public web presence), and if it doesn't, it's missing some features that would be very useful. Of course, one could use this argument to say Pyblosxom host it's own issues... but that should be for the future, not for now. |
Thanks for helping keep SourceForge clean.
X