Developers Needed!! : Fedora Tracker

[Brad Smith]

Hello all,

Once upon a time, around the time FC2 came out, I released a web
tool called Fedora Tracker (http://www.fedoratracker.org), which
indexes the various apt and yum repositories out there into a
single searchable database. It enjoyed some popularity and I was
happy to contribute to the usability of Fedora.

However, some of you may have noticed that Fedora Tracker indexes
far, far fewer repositories for FC4 than it did for previous
versions. This is because, having been under the impression that
most yum repos wouldn't adopt the new xml metadata format until
FC5, I didn't include support for it in the most recent update.
Obviously this proved to be a mistake and as a result Fedora
Tracker has become significantly less useful.

I've been waiting ever since that last update (around the time
FC4 came out) for my work load to relax enough to give me time
for another one. Alas, this doesn't seem to be happening. My
responsibilities here at Red Hat are different than they were
when I started Fedora Tracker and I just can't devote the same
amount of time to it that I used to.

In previous emails I have casually invited people from the
community to peruse the code and offer updates if they so
desired, but now Fedora Tracker really needs outside help. It's
been sitting there, more or less useless, for months now and I
want to see it back up to snuff. So, if you are a python
developer with some time to contribute to a worthy project, here
are the details:

Code is at http://sourceforge.net/cvs/?group_id=105932
 - trackerClass.py contains most of the front-end code
 - tpClass.py contains most of the back-end code
 - repo.py contains most of the package-handling code

Major tasks that are currently TODO

Top Priority:
---------------------------------------------------
- Add support for yum xml repos
 	The ideal way to do this would be to alter the yumRepo class
 	definition in repo.py (in particular the retrieve() and
 	update() methods) to check for and handle xml metadata before
 	looking for traditional header.*info files. The object would
 	be to pull down the relevant xml files and use them to build
 	repo.rpmInfo objects, which are used as a generic
 	representation of package metadata within Tracker.
	
Lower priority
---------------------------------------------------
- Switch to a templating engine for html
	I will be the first to admit that the way the frontend html
	is managed is horrendous. We need to move to some sort of
	templating engine. I've never used one before, so if you have
	a favorite and are willing to devote the time, please write
	me with a proposal.
	
- Performance enhancements
	Searches still run a lot slower than I would like. Optimizing
	database queries is not something I have much experience
	with. I've figured out a trick here and trick there, but I'm
	sure there is more that can be done. Effort here will be
	hindered by the fact that I'm currently the only one with
	direct access to the database (see next item)
	
- Move to more flexible hosting
	My current webhost is great, but they seem to be designed
	around the assumption that only one person manages each site
	that they host. As such, a lot of the above tasks will be
	more difficult since I'm the only one who will have actual
	shell access to the system. I'm currently working with them
	to try and find an alternative, but if that fails I'd be
	interested in hearing from anyone who thinks they could offer
	web/python/mysql access to a larger group of developers.
	
	
If anyone has the time and expertise to offer on one or more of
these tasks, please drop me an email, take a look at the code and
feel free to ask me any questions (I can arrange to meet on irc
as well). If this email actually generates some interest, then we
can look into setting up a mailing list, wiki or similar. I've
never actually maintained a project with multiple developers
before, so general advice about how I might approach this better
would also be great.

Thanks,
--Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051011/5edd7205/attachment.sig>