[U-Boot-Users] Changes to U-Boot Development Process

Aubrey Li aubrey.adi at gmail.com
Fri Jan 26 05:22:55 CET 2007


On 1/18/07, Wolfgang Denk <wd at denx.de> wrote:
> Hello,
>
> many of you know  all  too  well  that  we  have  problems  with  the
> development  process  of U-Boot. The biggest problem is that it takes
> much too long until new contributed code  finds  it's  way  into  the
> public source code repository.
>
> Switching from CVS to git helped a lot on the technical side. It  was
> especially  important  as  it also opened the door for organizational
> changes, which are urgently needed.
>
> We've been discussion these issues for some time,  and  here  is  our
> joint proposal. "We", that is mostly Detlev Zundel, Stefan Roese, and
> me  (Wolfgang  Denk).  Of  course  we  also had input form many other
> sources.
>
>
> As this mail will propose quite a fundamental change for  the  U-Boot
> project, please allow us to introduce it with a few short reflections
> on the current state of affairs.
>
> Being a regular reader of this list you will be well aware that  even
> with  all the problems in the development process and some ugly areas
> in the U-Boot code (like the #ifdef mazes)  there  is  one  important
> feature:  that's  the  quality  of  the  U-Boot  code  base  -  being
> highlighted quite well by the literal absence of temporary  breakages
> in  the  development  code base. This alone allows for the well known
> "use the latest code from the repository" answer when someone  enters
> the  grounds  of this project for the first time. It is well worth to
> reflect on this quality for a little while.
>
> Having done that we may well ask where this quality  comes  from?  We
> think  that anybody reading this list only for a limited time will be
> able to come up with the answer, namely  the  continuous  maintenance
> effort  of  Wolfgang  and  his modus operandi of personally reviewing
> nearly each and every contribution in this multi-architecture project
> supporting hundreds of boards. It should  be  obvious  how  important
> such  a  level  of  code  review  is to keep U-Boot from falling into
> disconnected pieces - just think of the effort  to  keep  aspects  of
> U-Boot similar across all supported architectures.
>
> But of course even Wolfgang only  has  24  hours  per  day,  and  the
> positive  effect  of this maintenance mode has shrunk continuously in
> comparison to the downside  of  the  embarassingly  long  backlog  of
> patches  posted  on  this  mailing  list  waiting  to  be  processed,
> rendering new lines of development very difficult to say the least.
>
> So the time is more than ripe to change this while explicitely trying
> to keep the quality of the  project  on  the  high  grounds  that  we
> brazenly claim for it :)
>
> Gladly there are other projects in the F/OSS community that are worth
> taking a peek at to snatch a hint or two on how we  can  tackle  this
> task.
>
> Considering all this we propose a change in  maintaining  the  U-Boot
> code base to a model similar to what is currently being done with the
> Linux  kernel,  namely  we  would  like  to  establish a community of
> "custodian"  maintainers,  responsible   for   certain   sub-systems,
> aspects, architectures, or board families of the U-Boot source tree.
>
> We would like to follow the Linux precedent by assembling a  list  of
> people  willing  to  invest  time  and  effort into this; the already
> existing MAINTAINERS file will serve  a  new  function  to  list  the
> individual  custodians with their corresponding area of responsibilty
> and contact information.
>
> Each custodian will have to administrate  his  or  her  git  tree  to
> streamline transparent development and integration (pulling) into the
> "official"  U-Boot repository. If the need should arise (for example,
> if a custodian doesn't have convenient means  to  host  it  himself),
> DENX will of course be glad to host such trees.
>
> The stated goal of this change of course is to spread the  burden  of
> maintaining U-Boot to more shoulders so we can hopefully dramatically
> cut  down  on  the  current lag between a patch being proposed on the
> mailing list and being processed - be that  accepting,  rejecting  or
> openly discussing it with the community.
>
> As you must have realized by now, this cannot  be  done  without  the
> community  participating,  so  what  do  you  think of this idea? Any
> comments or suggestions?
>
>
> Of course we should be honest right  upfront  and  state  that  as  a
> custodian  you  would  be  fully  responsible  for "your" part of the
> U-Boot source tree and it is unfortunately necessary,  that  you  are
> able to commit to a certain amount of time and willingness to discuss
> topics on the mailing list for this maintenance.
>
> Do we have an immediate line of volunteers raising in the first row?
>
> Skimming through the archives we came up with a list of people  which
> the  U-Boot  project  already  is indebted to and probably being good
> candidates for custodians. Of course this list cannot  and  does  not
> want  to  be  a  "credits"  list  of  all  the valuable people having
> contributed, so please don't attribute anything else to it as being a
> starting point for this new maintenance mode. Also there are multiple
> suggestions where ultimately of course we would like the community to
> decide.
>
> So with all these precautions in place, here we go:
>
> ARM architecture        Richard Woodruff, Peter Pearse
> AVR32 architecture      Haavard Skinnemoen
> Blackfin architecture   Aubrey Li

I'd be honored to take responsibility for Blackfin architecture.

Best regards,
-Aubrey




More information about the U-Boot mailing list