[U-Boot] Merge Process

[Cem Eliguzel]

Dear Wolfgang,
Our ultimate purpose is to have our architecture become one of the publicly
supported architectures by U-Boot.
What I really want to know is that should we always follow the master branch
of original repo? I see several different branches as well.
At the end, the patches we'll send to the mailing list will probably have a
big size. Should we just send the whole patch or?

Regards,
Cem

2009/6/18 Wolfgang Denk <wd at denx.de>

> Dear Cem,
>
> in message <90679b950906180633pf351261u7e581fc723806759 at mail.gmail.com>
> you wrote:
> >
> > We have, here at Ubicom <http://www.ubicom.com>, an ongoing process to
> port
> > u-boot to our architecture. Last week we decided to merge the upstream
> > u-boot codes to our local branch on which had forked from the upstream
> > branch about 8 months ago.We successfully managed to merge remote master
> > branch to our local branch. Is that the correct way of doing this? I
> mean,
>
> It depends on what you are trying to do. If all you want to have is a
> out-of-tree repository with your stuff in, this may work for you.
>
> If you plan to ever send your patches back upstream, then this is not
> what you want to do. In such a case you instead want to rebase your
> local branch against the remote master branch, so you can generate
> patches against the master branch that can be submitted on the mailing
> list.
>
> > should we synchronize with master branch? Is there any convention for the
> > merge process?
>
> There are no conventions for private repositories - you do what suits
> your purposes best. It's only the communication  with  the  community
> (i.  e. how to submit patches upstream) which is well defined and do-
> cumented.
>
> 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
> But the only way of discovering the limits  of  the  possible  is  to
> venture a little way past them into the impossible.
>                         - _Profiles of the Future_ (1962; rev. 1973)
>                  ``Hazards of Prophecy: The Failure of Imagination''
>