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.
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?
Regards,
Simon

On Sat, Dec 1, 2012 at 5:42 PM, Simon Glass <sjg@chromium.org> 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.>> 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?>
Maybe it is the time to move patman to another git repository?
patman is nice for many projects so maybe it could live outside U-Boot git?

Hi Otavio,
On Mon, Dec 3, 2012 at 4:12 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>[snip]
> Maybe it is the time to move patman to another git repository?>> patman is nice for many projects so maybe it could live outside U-Boot git?
Maybe one day, but we still have a number of things to sort out - e.g.
the threading issue Wolfgang raised. Also I don't think patman is
widely used even in U-Boot, and having it here promotes its use. What
other projects actually use it at this stage? (yes I see Doug's
patches aimed at supporting Linux better).
Regards,
Simon
>> --> Otavio Salvador O.S. Systems> E-mail: otavio@ossystems.com.br http://www.ossystems.com.br> Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br>

On Mon, Dec 3, 2012 at 10:27 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Otavio,>> On Mon, Dec 3, 2012 at 4:12 AM, Otavio Salvador <otavio@ossystems.com.br>> wrote:> >[snip]>> > Maybe it is the time to move patman to another git repository?> >> > patman is nice for many projects so maybe it could live outside U-Boot> git?>> Maybe one day, but we still have a number of things to sort out - e.g.> the threading issue Wolfgang raised. Also I don't think patman is> widely used even in U-Boot, and having it here promotes its use. What> other projects actually use it at this stage? (yes I see Doug's> patches aimed at supporting Linux better).>
I've been using it a lot! It is your call about moving it outside U-Boot
git or not but I do believe it would be easier to find users (specially
among other projects) if it were in a standalone tree. It would also allow
for independent release cycle (which would be good).
(this is my point of view)

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.