Re: [Xen-devel] [Hackathon Minutes] Xen 4.4 Planning

[Ian Murray <murrayie@xxxxxxxxxxx>]

----- Original Message -----
> From: Alex Bligh <alex@xxxxxxxxxxx>
> To: Ian Murray <murrayie@xxxxxxxxxxx>; xen-devel@xxxxxxxxxxxxx
> Cc: Alex Bligh <alex@xxxxxxxxxxx>
> Sent: Friday, 14 June 2013, 8:01
> Subject: Re: [Xen-devel] [Hackathon Minutes] Xen 4.4 Planning
> 
> Ian,
> 
> --On 14 June 2013 00:56:14 +0100 Ian Murray <murrayie@xxxxxxxxxxx> wrote:
> 
>>  When you talk about "stuff" breaking between major releases, are 
> you
>>  talking about Xen code not functioning or your code failing because of
>>  changes in Xen? If the latter, are we talking designed changes in Xen's
>>  behaviour or non-designed ones (=bugs)?
> 
> Both.
> 
> As an example of the first, the API changed very significantly between
> 3.x and 4.1, and 4.1 and 4.2. Some of the API changes were subtle (e.g.
> what you had to do across a fork()).

But surely, this is your business. This is what you do. Sounds like you want 
API changes to be held back for the entire community so your company has to do 
less work.


> 
> As an example of the second, see the very long thread with O_DIRECT
> in the subject line.
> 
>>  I am at a loss as to what is wrong with contributing a few bug fixes back
>>  if you're technically capable of finding and fixing... I am not feeling
>>  the community spirit here.
> 
> There's nothing wrong with that, and we have done. However this thread
> is about development cycles. Critical stuff breaks, we know that.
> That should happen in the unstable version. Patches that fix critical
> stuff should be made in the unstable version, not the stable version.

Do *you* test unstable and point out the critical bugs BEFORE it goes stable? 
If you don't, then don't be surprised when bugs crop up... 


> 
>>  Also, a little bit of Googling tells me that Flexiant (that is the 
> "we"
>>  in all of this, right?) provides cloud software to third-parties and does
>>  not provide cloud services itself. To make your product work reliably
>>  with Xen for your customers, are you distributing your own patches for
>>  Xen to these third-parties?
> 
> Yes. We ship with a patched version of xen. All our patches have been sent
> here and are on github. If the implication is that we're somehow keeping
> these to ourselves, you have that totally wrong. We would like nothing
> better than all our patches to be in mainline. For 4.2 we are currently
> carrying one patch for fixing the tsc (see 'clock stalled on live
> migration') which is a backport of a 4.3 patch here, and my minideb
> patch which is a packaging change which (for quite understandable
> reasons) people don't want in mainline. In the past, we've carried
> tens of patches - see the live migrate on qemu-upstream-dm for 4.2
> patch series I posted here, since accepted.

I looked on your website and couldn't find any download section for patches or 
a pointer to github or anything. I am not a lawyer but I didn't get the 
impression that sticking patches on a mailing list was fulfilling ones 
obligation under the appropriate licence. So please can you link from your 
company website to your github were these patches are available.

One aspect from your previous email I'd like to pickup on, when you mentioned 
KVM not having these issues, are you compiling from the source or using a 
distribution version? If the latter, then I think that is an unfair comparison.


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

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