[U-Boot-Users] u-boot patch submission process

[Jerry Van Baren]

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