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.