Re: [PATCH] tools/seabios: override $(PYTHON)

[Ian Campbell <Ian.Campbell@citrix.com>]

On Mon, 2012-02-20 at 10:37 +0000, Christoph Egger wrote:
> On 02/09/12 12:59, Ian Campbell wrote:
> > On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> >> Pass PYTHON=$(PYTHON) to gmake when building seabios.
> >> This fixes seabios build error
> >> 'python not found'
> >> along with the patches from Kevin O'Connor.
> >>
> >> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
> >
> > Acked-by: Ian Campbell<ian.campbell@citrix.com>
> >
> 
> Please apply this patch and update SeaBIOS.
> Keven O'Connors patches went upstream on Feb 8th.

I was hoping to track SeaBIOS stable branches so I am reluctant to
simply update to a random commit on the development branch.

Currently we are tracking the upstream 1.6.3-stable branch in the
xen-unstable branch of our seabios.git. In hindsight this might have
been an error since it means that our branch will only be non-rebasing
until we switch to 1.6.4 or 1.7.0 (whichever comes next).

I'm not sure how best to approach this, obviously I could create a
1.6.3-stable-xen branch and backport your fix to it. I'd like to decide
what approach I should take when the upstream latest-stable branch
changes first though.

My immediate thought is that I should remove the "xen-unstable" branch
from our tree and instead push upstream's 1.6.3-stable branch and then
push my 1.6.3-stable-xen branch and switch to that. When new stable
branch X.Y.Z-stable happens upstream I will simply create a new
X.Y.Z-stable-xen based on it.

However I am not sure what to do with the "master" branch of our tree.
Previously I just omitted it since it has no real meaning but that
caused confusion and people wanted me to put something there.

I don't want to track the upstream devel branch since I don't want users
who clone our tree to think we support that as is. I don't want to push
the currently supported stable branch because that would necessarily
make master a rebasing branch.

The xen-unstable build system itself uses explicit commit numbers or
tags so isn't really effected.

IanJ -- what do you think?

Ian.