Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

On Wed, Jan 10, 2018 at 5:50 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 10.01.18 at 14:34, <george.dunlap@xxxxxxxxxx> wrote:
>> I'd like to propose a new appraoch:
>>
>> 1. Immediately release Amazon's v1 series for people who can / prefer
>> to use the HVM + sidecar option.
>> - Advisory and HOWTO should include who should use this option, and
>>   how to do it.
>> - Check the series into a branch on xenbits, and add a signed tag
>> - HOWTO-vixen, and sidecar script, to be included in the advisory.
>>
>> 2. As soon as possible, release Citrix's series for people who can /
>> prefer to use the PVH + toolstack option.
>> - Immediate work should focus on getting PVH + toolstack functionality
>>   ready to release
>> - When ready, advisory and HOWTO should include who should use this
>>   option and how
>> - Either check the series into a branch on xenbits, or into
>>   staging-4.10
>> - HOWTO-pvh to be included in the advisory.
>>
>> This should allow us to get a solution to the widest number of users
>> in the shortest amount of time; it also allows us to leverage the
>> testing efforts of both Amazon (for breadth of Xen versions) and
>> Citrix (for depth of functionality).
>>
>> That takes the pressure off us to check in one or the other version of
>> the patch series.
>>
>> Going forward, we could work towards the convergence of functionality
>> from either patch series.  But it looks superficially at least like
>> the Citrix series is closer to the convergence point, and so it seems
>> like using that as a starting point would make the most sense.
>
> There are a couple of instances of "a branch", and I'm not really
> clear on which one that would be, yet in part my opinion depends
> on that, as this will affect what state certain branches will be in
> for subsequent work. As I agree with the PVH shim being the
> better baseline for work going forward, in particular I wouldn't like
> to see the Vixen series becoming the base of any branch going to
> be maintained going forward.

What I would suggest is the following:

1) Merge Vixen into staging

2) Backport Vixen into stable-4.10 and cut a release

3) Immediately begin bringing in PVH shim into staging

4) While doing (3), avoid breaking HVM shim but take full liberty to
    remove Vixen bits and replace.

5) Release 4.11 once PVH shim is ready

I think releasing something to users and then doing a totally
different implementation is going to be extremely painful.

The advantage of merging to staging is that it becomes possible to
bisect regressions.

There isn't really much of a user facing difference here so if the entirety
of Vixen was replaced under the covers for 4.11, as long as we are able
to test continuously and avoid regressions, no one would notice the
difference.

However, if you start from a different base for 4.11 and release something
that regresses from a unique Vixen branch, it's going to be painful trying
to move people off of that branch.

Regards,

Anthony Liguori

> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel