[U-Boot] x86 cleanup patches

[U-Boot] x86 cleanup patches

[Graeme Russ]

Hi Wolfgang, Gabe,

I have two x86 tidy-up patch series that I intend to apply in the next 2-3
weeks to a 'next' branch on the x86 repo. Being 'next', these patches are
intended for the current merge window which closes on December 12

Please be aware that the latest series (checkpatch cleanup) is designed to
be applied first, but it was actually created _after_ the 'Various x86
cleanups' series and hence, there is a wee little bit of incompatibility
between the two (and silly me should have called the latest one v0 as
well...). The conflicts aren't so bad - I already have them resolved but
the second series is not checkpatch clean yet. Before I apply this series
to 'next' I will be posting a unified patch set in the next week or so - It
will be a 12 part series which will line up 1-to-1 so I'll be setting the
in-reply-to to thread from the current patches. In the meantime, please:

1) Have a look at the two independent series and let me know if there is
any glaring issues I need to address
2) Let me know if you need more than two weeks
3) Be prepared to rebase any current x86 patches against 'next' in three
weeks time (unless otherwise informed)

Gabe, going by this schedule, there will be a good two weeks between the
x86 cleanup hitting 'next' and the merge window closing - I think this
should be plenty of time to get the rebased coreboot patches onto the
mailing list before the merge window closes, and ideally into x86/next for
a speedy pull into mainline before the end of the year :)

Regards,

Graeme

[U-Boot] x86 cleanup patches

[Wolfgang Denk]

Dear Graeme Russ,

In message <4EB67A6E.2090902@gmail.com> you wrote:
> 
> I have two x86 tidy-up patch series that I intend to apply in the next 2-3
> weeks to a 'next' branch on the x86 repo. Being 'next', these patches are
> intended for the current merge window which closes on December 12

You confuse me.

Currently the merge window is closed.  The next release is scheduled
for December 12.  ONly then, the _next_ merge window will open.

> Please be aware that the latest series (checkpatch cleanup) is designed to
> be applied first, but it was actually created _after_ the 'Various x86
> cleanups' series and hence, there is a wee little bit of incompatibility
> between the two (and silly me should have called the latest one v0 as
> well...). The conflicts aren't so bad - I already have them resolved but
> the second series is not checkpatch clean yet. Before I apply this series
> to 'next' I will be posting a unified patch set in the next week or so - It
> will be a 12 part series which will line up 1-to-1 so I'll be setting the
> in-reply-to to thread from the current patches. In the meantime, please:

This being mostly cleanup, and we still being relatively early in the
stabilization phase, I would also accept this stuff now.

> 1) Have a look at the two independent series and let me know if there is
> any glaring issues I need to address

I will, time permitting.

> 2) Let me know if you need more than two weeks

?

> 3) Be prepared to rebase any current x86 patches against 'next' in three
> weeks time (unless otherwise informed)

?

> Gabe, going by this schedule, there will be a good two weeks between the
> x86 cleanup hitting 'next' and the merge window closing - I think this

Which merge window are you talking about?

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
GUIs  are  virtually  useless.  Learn  tools.  They're  configurable,
scriptable, automatable, cron-able, interoperable, etc. We don't need
no brain-dead winslurping monolithic claptrap.
                               -- Tom Christiansen in 371140df at csnews

[U-Boot] x86 cleanup patches

[Graeme Russ]

Hi Wolfgang,

On 07/11/11 06:09, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4EB67A6E.2090902@gmail.com> you wrote:
>>
>> I have two x86 tidy-up patch series that I intend to apply in the next 2-3
>> weeks to a 'next' branch on the x86 repo. Being 'next', these patches are
>> intended for the current merge window which closes on December 12
> 
> You confuse me.
> 
> Currently the merge window is closed.  The next release is scheduled
> for December 12.  ONly then, the _next_ merge window will open.

Oops, what you're saying is what I meant - next merge window

>> Please be aware that the latest series (checkpatch cleanup) is designed to
>> be applied first, but it was actually created _after_ the 'Various x86
>> cleanups' series and hence, there is a wee little bit of incompatibility
>> between the two (and silly me should have called the latest one v0 as
>> well...). The conflicts aren't so bad - I already have them resolved but
>> the second series is not checkpatch clean yet. Before I apply this series
>> to 'next' I will be posting a unified patch set in the next week or so - It
>> will be a 12 part series which will line up 1-to-1 so I'll be setting the
>> in-reply-to to thread from the current patches. In the meantime, please:
> 
> This being mostly cleanup, and we still being relatively early in the
> stabilization phase, I would also accept this stuff now.

OK - There is only one patch that adds new 'features' - The 'Add multiboot
header' but that's just some canned static data, no code

>> 1) Have a look at the two independent series and let me know if there is
>> any glaring issues I need to address
> 
> I will, time permitting.

Thanks

>> 2) Let me know if you need more than two weeks
> 
> ?
> 
>> 3) Be prepared to rebase any current x86 patches against 'next' in three
>> weeks time (unless otherwise informed)
> 
> ?
> 
>> Gabe, going by this schedule, there will be a good two weeks between the
>> x86 cleanup hitting 'next' and the merge window closing - I think this
> 
> Which merge window are you talking about?

Sorry for the confusion - I intend to get Gabe's patches into x86/next as
soon as the next merge window opens on December 12

Regards,

Graeme

[U-Boot] x86 cleanup patches

[Wolfgang Denk]

Dear Graeme Russ,

In message <4EB6E405.4060509@gmail.com> you wrote:
> 
> > This being mostly cleanup, and we still being relatively early in the
> > stabilization phase, I would also accept this stuff now.
> 
> OK - There is only one patch that adds new 'features' - The 'Add multiboot
> header' but that's just some canned static data, no code

So let's add the stuff now.


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
"IBM uses what I like to call the 'hole-in-the-ground  technique'  to
destroy  the  competition.....  IBM digs a big HOLE in the ground and
covers it with leaves. It then puts a big POT OF GOLD nearby. Then it
gives the call, 'Hey, look at all this gold, get over here fast.'  As
soon  as  the competitor approaches the pot, he falls into the pit"
                                                     - John C. Dvorak

[U-Boot] x86 cleanup patches

[Graeme Russ]

Hi Wolfgang,

On Mon, Nov 7, 2011 at 6:50 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Graeme Russ,
>
> In message <4EB6E405.4060509@gmail.com> you wrote:
>>
>> > This being mostly cleanup, and we still being relatively early in the
>> > stabilization phase, I would also accept this stuff now.
>>
>> OK - There is only one patch that adds new 'features' - The 'Add multiboot
>> header' but that's just some canned static data, no code
>
> So let's add the stuff now.

OK, I'll expedite posting a merged patchset

Regards,

Graeme

[U-Boot] x86 cleanup patches

[Graeme Russ]

Hi Gabe,

On 13/11/11 14:08, Gabe Black wrote:
> So to clarify, what repository/branch should I be applying my patches to,
> and when? For instance, where should my patches that create a coreboot
> board go? I have other patches which depend on those so I'd like to get
> them moving again. Also having a build target makes it possible to verify
> that everything still compiles. My patches have been tested on our tree and
> I've been trying not to change them more than necessary to try to preserve
> their correctness, but that's not a good long term strategy.

That's actually a very good question - and the answer relies in part on the
state of the merge window and partly on the type of patch (cosmetic,
bug-fix, performance improvement, new feature, etc.)

Firstly, a bit of history :) As I mentioned previously, because the merge
window was closed, I was planning on creating a u-boot-x86/next for you to
rebase against. I was going to put my cleanup patches in u-boot-x86/next,
have you rebase against it and I would apply them to u-boot-x86/next. I
would then send a pull request to Wolfgang for u-boot-x86/next when the
merge window re-opened after the next release (scheduled for the 12th
December). However, Wolfgang felt that the cleanup changes could be pulled
into the current release given the fact that they are mainly cosmetic and
do not add any new major features. So, I cleaned up that patchset, posted
the revision to the ML and waited a few days before applying them last
night to u-boot-x86/master. Now your patches are bug fixes, so I'll apply
them to u-boot-x86/master and send a pull request to Wolfgang.

Of course, I could of sent a pull request to Wolfgang, waited for Wolfgang
to pull then asked you to rebase to u-boot/master, applied your patches to
u-boot-x86/master and then asked Wolfgang to pull again - More work, more time.

So, in future:
 - I will keep keep u-boot-x86/master rebased to u-boot/master with 'any
   pending x86 related patches either submitted to the ML while the
   previous merge window was open' or 'post merge window closure bug
   fixes submitted to the ML' committed on top
 - I will keep keep u-boot-x86/next rebased to u-boot-x86/master with 'any
   non bug fix patches posted to the ML after the merge window closed'
   committed on top

Here's where it gets a little tricky:
 - While the merge window is OPEN, send patches against u-boot-x86/master
   before sending to the mailing list (features and bug fixes)
 - While the merge window is CLOSED:
     - When submitting features, send patches against u-boot-x86/next
     - When submitting bug fixes, send patches against u-boot-x86/master

Of course, there may be times when a patch submitted while the merge
windows is closed needs to be moved from next to master or visa-versa -
I'll let you know and if it applies to the other branch cleanly, there is
no need for you to do anything, otherwise I'll ask for a rebase

When the merge window opens after the release, I will rebase
u-boot-x86/master against u-boot-x86/next.

Wolgang - When do you prefer the pull requests - Should I send as soon as
the window opens, or should I keep collecting patches and send a bigger
pull after the merge window closes?

I'll try to keep u-boot-x86/master in sync with u-boot/master, but this is
an after hours job and life can take precedence sometimes - If you notice
I've let it slip too far, drop me a line and I will prioritise a rebase

I hope that answers your questions

Regards,

Graeme

P.S. All of the above is subject to Wolfgang correcting me ;)

> 
> Gabe
> 
> On Sun, Nov 6, 2011 at 1:22 PM, Graeme Russ <graeme.russ@gmail.com
> <mailto:graeme.russ@gmail.com>> wrote:
> 
>     Hi Wolfgang,
> 
>     On Mon, Nov 7, 2011 at 6:50 AM, Wolfgang Denk <wd@denx.de
>     <mailto:wd@denx.de>> wrote:
>     > Dear Graeme Russ,
>     >
>     > In message <4EB6E405.4060509@gmail.com
>     <mailto:4EB6E405.4060509@gmail.com>> you wrote:
>     >>
>     >> > This being mostly cleanup, and we still being relatively early in the
>     >> > stabilization phase, I would also accept this stuff now.
>     >>
>     >> OK - There is only one patch that adds new 'features' - The 'Add
>     multiboot
>     >> header' but that's just some canned static data, no code
>     >
>     > So let's add the stuff now.
> 
>     OK, I'll expedite posting a merged patchset
> 
>     Regards,
> 
>     Graeme
> 
>