Re: [Xen-devel] recent seabios tag updates

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.02.12 at 10:28, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote:
>> Hi Ian,
>> 
>> with these I'm getting the impression we're making it, just like for qemu,
>> a requirement to use the xenbits mirror rather than the original as well,
>> even more so given that the two post-1.6.3.1 commits the mirror now
>> has don't even exist in the upstream tree (yet), making this not even a
>> mirror anymore.
> 
> I cherry picked both of those commits directly from the mainline SeaBIOS
> tree, so they are upstream.

Then I may be tracking (and looking at) another mirror rather than
upstream. What is "upstream" here?

>> I really had hoped that we would bring down (rather than up) the
>> number of private clones of upstream trees, and provide true mirrors
>> on xenbits really just for developers' convenience. Any word on the
>> overall picture?
> 
> The reality is that we will sometimes need to backport fixes to stable
> trees which are specific to Xen and which upstream declines to take into
> their own stable branch (e.g. because they need to balance the risk of
> taking a Xen thing against other non-Xen users of their stable branch).
> 
> It is also possible that we will want to backport new features from
> upstream mainline in order to better expose them to Xen users and
> developers prior to a new upstream release occurring. For example I
> expect that the upstream qemu support for save/restore will fall into
> this category.
> 
> In this case I should have asked upstream about a backport to their
> stable branch before taking them myself which I neglected to do, sorry.
> I have approached upstream about these two now and will fixup with the
> appropriate merging in 1.6.3-stable-xen if the decide to take them.
> 
> The rules which I will be applying (and which e.g. Stefano will be
> applying for the qemu tree) will be similar to the upstream kernel
> stable rules -- primarily that a commit must be included in the relevant
> mainline branch before being proposed for backport. This ensures that
> the fork will be bounded due to being reset each time we rebase to a new
> upstream stable release.

Okay, thanks for the explanation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel