[U-Boot] Please pull u-boot-x86.git

[Tom Rini <trini@ti.com>]

On Sat, Dec 01, 2012 at 11:42:28AM -0800, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, Dec 1, 2012 at 10:32 AM, Tom Rini <trini@ti.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 12/01/12 09:38, Simon Glass wrote:
> >> The following changes since commit
> >> b8715d8def240014da5614a4f940130ec06d9ebf:
> >>
> >> Merge branch 'master' of git://git.denx.de/u-boot-fdt (2012-11-29
> >> 06:41:56 -0700)
> >>
> >> are available in the git repository at:
> >>
> >> git://git.denx.de/u-boot-x86.git master
> >>
> >> Gabe Black (6): x86: Allow compiling out realmode/bios code x86:
> >> Add an fdt pointer to the global data structure x86: Add a minimal
> >>  device tree for alex x86 x86: Add a default implementation for
> >> cleanup_before_linux() x86: Add a dummy implementation for
> >> timer_get_us x86: Include types.h explicitly in the i386 version of
> >> io.h
> >>
> >> Simon Glass (4): x86: coreboot: Decode additional coreboot sysinfo
> >>  tags x86: Select stdio devices for coreboot x86: Remove coreboot
> >> start16 code x86: Define CONFIG_SYS_VSNPRINTF for coreboot
> >>
> >> Stefan Reinauer (4): x86: coreboot: Drop sysinfo.c x86: video: Add
> >>  coreboot framebuffer support x86: Fix typo in pcat_timer.c x86:
> >> Don't spam POST80 codes with slow IO functions
> >>
> >> Vadim Bendebury (2): x86: Add CBMEM console driver for coreboot
> >> x86: Add console command to display CBMEM console buffer
> >
> > I know there's outstanding x86 work, but was all of this in some
> > series that was posted before the merge window closed?  Thanks!
> 
> This set of patches was posted between 13th and 20th October. I
> actually have more patches in my todo list on patchwork (mostly newer
> ones to 3 November, but a few very old like 4 of those in the first
> pull request this week).
> 
> I took over as maintainer right near the end of the merge window and
> sorted out repo access 10 days ago, so I am definitely playing catch
> up. All going well I should work through the rest next week.

OK, thanks.

> While talking about patches I see that the patman patches are assigned
> to me. I will of course review them, but what should I do after that,
> as they are not x86? Also they are outside the merge window for this
> release, but will you accept 'next' pull requests at some point?

For patman patches that you didn't author/post, I think I assigned them
to you to review and then pass back to me to pickup.

For the next branch, I would like to see custodians take things in that
they're happy with, but came in post merge window.  How it gets into the
main tree, I'm still thinking about.  Having a lot of people using a
rebased tree was shown to be a pain last time around.  I'm tempted to
say we should try something more Linux Kernel like and say put patches
that are ready into a branch against what they're tested / posted
against, and send pull requests once the merge window opens.  But I know
there's a lot of nuance to the process there too.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121203/0daf8a18/attachment.pgp>