[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 at gmail.com
> <mailto:graeme.russ at gmail.com>> wrote:
> 
>     Hi Wolfgang,
> 
>     On Mon, Nov 7, 2011 at 6:50 AM, Wolfgang Denk <wd at denx.de
>     <mailto:wd at denx.de>> wrote:
>     > Dear Graeme Russ,
>     >
>     > In message <4EB6E405.4060509 at gmail.com
>     <mailto:4EB6E405.4060509 at 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
> 
>