Wolfgang Denk wrote:
[snip]
When I scan patches, this requires that I not only check the patch, but all the following thread(s) it spawns. This is not only time-consuming, but has also good potential to lose track of what's been done and what not (yes, we are missing a patch tracking system, and yes, we are working on it - it's the highest priority of our admin here right now). The only chance for me to keep track is to go through more or less chronologically. That means that patcehs don't get applied in priority order (unless somebody explicitely triggers me), but sequentially.
As for the rate of progress, trying to pressure anyone to work faster is not a good idea, I know that. But is there any way we can change the process and move more work down the hierarchy? It seems to me you're
Yes, there is a way. I must get rid of the time-consuming task to check which patches have been picked up by some custodian, and which not, and if not, if they have been rejected are are ready to be applied or what. For this we need a patch tracking system, where we can see immediately who is "responsible" for a specific patch.
That's top prio for me. And we are working on it.
Jeremy Kerr has a perl script that picks out patches: http://ozlabs.org/~jk/projects/patchwork/ http://patchwork.ozlabs.org/ - try before you buy I'm not sure how effective it is at following the threads. One VERY NICE thing about it is the "download" button that gives you a clean patch email. Unless I'm missing something, sites like gmane.org don't have a way of getting truly clean (unHTML-ized, no email obfuscation) versions of the archives.
Hmmm, Patchwork's threading capabilities appear to be less than gmane's http://thread.gmane.org/gmane.linux.ports.ppc.embedded/17429 vs http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=13060 and http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=13051 Based on a very cursory review, it looks like a good idea, but needs more polishing before it makes it to version 1.0.
Testimonial: http://laforge.gnumonks.org/weblog/2005/08/index.html
---------------------------------------------------------------------
For project management, I keep looking at Trac with the git plugin (not sure how well the git plugin works, but OLPC development uses it). My gut feel from browsing open source projects is that it is one of the more popular systems, but I don't know if it is a good match for u-boot/denx.de's needs. http://trac.edgewall.org/ The user list is pretty extensive: http://trac.edgewall.org/wiki/TracUsers
OLPC uses trac and git: http://dev.laptop.org/
---------------------------------------------------------------------
Django is an interesting dB / Python interface, the same problem space addressed by Ruby on Rails. http://www.djangoproject.com/
I have a vision of extending Trac, possibly through Django, to encompass more of the development lifecycle. In this discussion, for instance, rewriting Patchwork in python and then marrying it with Trac. Interestingly enough, Django uses Trac (and svn, but we won't hold that against it ;-).
[snipped the cork comment, much too graphic ;-]
Best regards, Wolfgang Denk
Best regards, gvb