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

[Wolfgang Denk]

In message <20080212112242.7c5c2e43 at dhcp-252-066.norway.atmel.com> you wrote:
>
> But to make things more confusing, I've seen you've applied other, less
> important patches while the tree was broken. If you had taken the time
> spent on one of those patches and applied one of the build fixes
> instead (doesn't matter much which one at this point -- we can always
> work out the details later), that would have helped even more.

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.

> doing pretty thorough review on everything that goes into the tree, and
> you're also sweeping up quite a few patches that the custodians didn't
> pick up. This does not scale very well...one of the most important
> responsibilities of a custodian is indeed review (or at least ensuring
> that someone else does it.)

You are right, this is indeed the main problem. I don't want to let
good patches disappear in a black hole just because nobody else cared
about them. At the moment, all I can do is review them all.

> Again, sorry for using such harsh words. But I do think we should
> discuss how to handle situations like this better in the future. Trying

Well, I've explained a few times before that we are working on a  bug
&  patch tracking system. Maybe I should have been more expolicit how
vitally important this is for my own work.

> to prevent it from happening at all is not productive -- we all make
> mistakes -- but this means dealing with it in a timely manner is all
> the more important. And it doesn't just happen in u-boot; the avr32
> architecture broke three times during the Linux 2.6.25 merge window (as
> did lots of other architectures). The difference is that the breakage
> was fixed almost instantly when I or someone else complained about it.

I'm always open for shortcuts - if I  see  something  is  urgent  I'm
willing  to  act  ASAP.  I  just  didn't see the 8xx SPI issue was so
critical - I knew there was a patch in the  queue,  so  what.  I  was
wrong  here. The most helpful posting was the one from Kim Phillips -
he raised both my attention *and* provided a repo to pull from.

> But note that whenever I'm complaining about patches not being applied,
> slow progress, or whatever, I'm really not complaining about _you_, I'm
> complaining about the process.

I understand this. But the process has bottlenecks, and sitting as  a
cork  in  such  one  while  the  pressure is building up below my *ss
doesn't make me happy either ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I haven't lost my mind -- it's backed up on tape somewhere.