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

[Aubrey Li]

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.

So does custodian have permission to push his commit into the official
repository or the present maintainers are still responsible for
pulling all of the subpart trees regularly and integrate into upstream
repository?

-Aubrey