Recently I mentioned that I hate releasing software. It’s true, and I’ve decided that the first part of fixing it is to tackle the presentation of software to the world.
My current scheme of darcs.complete.org for repositories plus bare directories on my gopher (yes, that gopher) site leaves a lot to be desired. There is no bug tracker, there are few screenshots, there is no consistency. It is also not easy to empower others to work on them directly.
At the same time, I am the sole or primary contributor to most of them. These are not huge kernel-sized projects. These are smaller, bite-size projects. So I don’t want or need a lot of overhead. I’ve been thinking about my options.
- I could just use sourceforge.net. I poked around there today, and all the advertising there is a real eyesore. Plus I figure that if anyone is getting paid for all my hard work, why should it be some random people that no longer write free software? On the other hand, it would be an easy way for my projects to gain visibility. Or I could use alioth, and give up both the advertisements and the larger visibility. But I don’t like giving up control over my site’s appearance, or behing beholden to others for backups, uptime, etc.
- I could use trac. It’s nice, and is the only option that supports darcs, and has a very cool wiki integrated into everything (even parsing out keywords from changelogs). On the other hand, downloads are — at best — attachments to wiki pages. There is no download manager. And you have to set up a separate trac instance for each project. That is a non-starter for me. If I can’t see all my bug reports at one place, the bug tracker will be too annoying to use.
- I could use gforge or savane. These are the sourceforge forks. Neither seems to be as resource-hungry as I expected, and debs are available for both. I could just install them locally and use them for my projects, though that seems like overkill. Plus, like SourceForge and Alioth, they have a crappy web-only bug tracker. I’d rather use something like RT that works by email. (Though RT is too resource-intensive to run on my server). However, web-only is better than nothing so I could hold my nose and use it.
- I could write my own. But I’d rather not, if there’s already something workable out there.
Is anyone else thinking about this? What are your thoughts?
Re: the bugtracker on trac, I use the RSS feeds for the timeline to aggregrate all incoming wiki/bugtracker/commits. That might make it somewhat less annoying.
Also, it might still be worthwhile to have multiple repos for a single trac instance. Trac will only be able to manage one of them (with the timeline and fancy source browser), but there is nothing stopping you from using the same bugtracker and wiki for them all.
There are tons of plugins for trac. As far as I recall, one of them is somewhat sane download manager.
Also it’s not really necessary to have one trac instance for each project. http://trac-hacks.org is a trac hosts many trac plugins in a single instance. Each plugin only gets it’s own component. For small projects it would be a reasonable way.
But they all share a single Subversion repository. That’s not all that ideal, but with darcs, it would be much worse. I have some projects that really are too large for this to work with.
Use Google Code for bug tracking, Google Pages for websites and downloads, and keep the darcs repo’s whereever you have them now.
I’d also recommend google code. For me sourceforge is slow. It crawls. But google code is fast. Although if you like to use darcs and not subversion, then it might not be worth it.
Trac is what we use at work. We have all projects in the same repository. We use components for projects and send mail about all changes to a mailing list that most of us subscribe. RSS is not a bad option either, I just prefer mutt.
As others have stated, downloads in trac is solvable. And trac improves at an amazing rate.
Google Code is a good choice.
If you want to host everything locally though, don’t give up on Trac. Sure, each little project will have its own trac instance, which should take maybe a few minutes to set up. Also, it triages bug reporting — little chance a bug coming from outside can be misreported against the wrong project.
For your sanity though, just funnel all the bug reports to a single mailing list. You can still close a bug with a commit message, so it’s not to heinous. One thing you lose is unified bug reports across projects, which arguably isn’t a huge feature in the first place.
I got tired of making releases and keeping homepages up to date for all my Haskell projects, so I wrote a program to do it:
[url]http://www.cs.chalmers.se/~bringert/darcs/hask-home/doc/[/url]
It assumes that you use darcs, Cabal, haddock, and probably makes some other assumptions too.
Use your python skills to add the feature to trac that a lot of other people want, namely making it so you can setup one trac instance for multiple projects.
Don’t spend your time coding something else from scratch, when you can improve something else that has a lot of the functionality that you already need. An improvement that a lot of others would find valuable (including myself).
Just dropped in to mention I’m back now. If you like roses, read Billy’s last post about his Dad’s.
Congrats on the five years! You are a cute couple. And too, for the house sale.
I programed a long time ago. Mine were used in house (NASA) but it gave me a good feeling to see it take wings. Just like a good blog.
..
..