[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