[U-Boot-Users] Added a custodian status page to denx.de/UBoot

[Aubrey Li]

On 4/5/07, Ben Warren <bwarren at qstreams.com> wrote:
> Jerry,
>
> On Thu, 2007-04-05 at 10:31 -0400, Jerry Van Baren wrote:
>
> > If we use branches:
> > 1) Primarily used in the custodian trees:
> >     a) Useful for keeping track of work in progress
> >     b) Specifies what Wolfgang needs to pull into the mainline
> > 2) Must be kept clean - delete ones no longer useful
> > 3) VERIFY/merge with the mainline BEFORE requesting a pull.  If Wolfgang
> >       finds a pull requires a merge, YOU HAVE FAILED as a custodian (or
> >       u-boot's world has shifted under your feet - probably the latter;-)
> >
> > I see 1b) as being very important.  Wolfgang has been VERY responsive
> > for pull requests (THANKS!) compared to the pre-custodian days.  If it
> > takes more than a few days to pull a set of changes into the mainline,
> > branches are the only practical way to keep track of what is pending.
> > Trying to say "pull from 7cd5da0fe877e7171a4cdd44880bce783132871a to
> > aea03c4e8c3a21ce43d3faf48a6e6d474c8bdf73" is NASTY (OK, that was a bit
> > of a paper tiger).
>
> I think I'm more in agreement with Wolfgang on this.  The master branch
> should be what he pulls from, and code there should be expected to be
> ready for inclusing in the main tree.
>
> I was thinking of using branches for less trivial changes.  For example,
> if somebody submits a new driver, the custodian would put in on a
> 'testing' branch after it passes coding style and peer-review of logic.
> He/she would then send out an invitation for testers.  After the
> custodian and others are satisfied, the branch is merged with master,
> and a pull request is made to Wolfgang.
>
> Branches could also be used for more radical re-factoring efforts.  For
> example, I'm not very happy with the mess that is 'eth.c', with all its
> #ifdef-wrapped initialize() functions.  When time permits, I'd like to
> do this in a cleaner way and invite others to help out with
> design/coding/testing.  Another example is the work Grant's doing on the
> memory commands.  It seems to me that branches are the way to go here.
>
> Maybe I'm over-complicating things.  Maybe we're all really in complete
> agreement and I just didn't parse your ideas properly.  Stranger things
> have happened...
>
I have some patches in hand, and they are not common enough to be
committed into mainline, but they are really useful for the user.
So, I'm thinking, keep two branches in the git repository,
one is for upstream, I put everything needed to this branch request
Wolfgang to review and merge;
the other is master, I apply all unacceptable patches on this branch,
so that user can clone it and simply build to get a more feature
u-boot.
The point that put all unacceptable patches to the master branch is
making git-clone like as cvs/svn checkout, user don't need to do
anything but only "make" the package and get the binary. Just my
thoughts.

Does this make sense?

-Aubrey