[U-Boot-Users] Please pull u-boot-mpc83xx.git mpc83xx branch into testing

[Grant Likely <grant.likely@secretlab.ca>]

On 9/25/07, Kim Phillips <kim.phillips@freescale.com> wrote:
> On Mon, 24 Sep 2007 16:47:58 -0600
> "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
> > On 9/24/07, Kim Phillips <kim.phillips@freescale.com> wrote:
> > > On Mon, 24 Sep 2007 23:52:29 +0200
> > > Wolfgang Denk <wd@denx.de> wrote:
> > >
> > > > In message <20070924161309.9f14b16e.kim.phillips@freescale.com> you wrote:
> > > > >
> > > > > > There is no merge window open at the moment.
> > > > > >
> > > > > ok, let me understand how you want this to work.
> > > > >
> > > > > my original intent was for you to pull 837x support into your /testing/
> > > > > tree so that gcl's mass-rename scripts could do their magic on the 837x
> > > > > board port too.
> > > >
> > > > No, that will not work. You would move Grant's base under his feet.
> > >
> > > this goes both ways.  True, Grant's work is more intrusive, but that
> > > just means that all work that is or can be affected by it be staged in
> > > a single common tree.  My understanding is you have designated the
> > > -testing tree for this particular purpose.
> >
> > I don't think that's quite true.  In the last merge window, -testing
> > got used to stage changes for the merge window with the least possible
> > impact.  In that case, it was Jon's CMD_* changes which needed to go
> > in first.
>
> Jon's CMD_* changes were performed in stages, with boards being added
> in between.  Sure, after each phase, things inevitably broke, and they
> were promptly fixed up again, by him and others.  Isn't that how your
> Kconfig changes are going to work (in phases)?
>
> > It makes total sense to stage changes in the custodian trees, but
> > Wolfgang retains the right to decide what order those changes get
> > staged into -testing, and also to request custodians to
> > merge/rebase/retest before pulling their tree.
>
> sure, and I can do that, I just wasn't aware of existing blockage.  I
> would have expected blockage to occur between the time you submit
> patches to the mailing list and when WD applies them to his tree.
>
> I just want your (and others') /subsequent/ patches to include 837x
> code, so I, and other custodians btw, don't have to duplicate your work
> unnecessarily and keep on having to play catch up.  But it sounds like
> you're not going to do it in phases, or, at least the phases are going
> to be clearly marked with releases 1.3.[123]?

Yes, the phases are going to be on the release marks.  I have no
intention of getting everything in by 1.3.1.

- Conditional compilation will definitely be ready and I hope will go
in.  This is the change I'm most concerned about being merged first
because of the merge conflicts which will occur in the Makefiles and
all the changes are done manually.  These changes are *almost* ready.
I've got a couple of board ports which are still not compiling
correctly that need to be fixed, then I'll post the patch set (in the
next day or so)

- Mass macro renames might go in for 1.3.1; but I need to test those
changes up the wazo before I post them.  Most likely I'll have a
script which automates this change, which means it can either go in
before or at the end of the merge window.

- I'm not even going to attempt migration to kconfig until 1.3.2 or 1.3.3.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195