[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Alex Bligh <alex@xxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • From: Ian Murray <murrayie@xxxxxxxxxxx>
  • Date: Fri, 14 Jun 2013 13:32:36 +0100 (BST)
  • Delivery-date: Fri, 14 Jun 2013 12:33:22 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PlOEXA+Lhyw1H62yHXfugTT6jWfB8K/uy/9W6qeRFl1LIyDWPud1FoK+oFd4s7NIHpEivIy2VTMEo9IBirmxGYt/7Zwxt1rCOvWKTsBS/lvvdN2m/dRZE8DnJlCIKZdiH5vRQFH7xHq5OpKpsU9PaDJQj09SPO6WgrtijZl3uWc=;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

> I think forward compatible APIs are a good thing. This is not
> controversial. I believe there are few people in the Xen community
> who think not having forward compatible APIs was anything but a mistake.

It certainly is a good thing, but if there is a need to change them then a 
major release is a good place to do it. Surely this is a governance issue, not 
a release cycle issue?

I have no idea whether the API changes you descrbe were a "mistake" or not as I 
don't use them.

>>>  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...
> Yes we do. If you want a concrete example, go search for the migration
> wallclock lockup thread this month.
>>  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.
> The fact it is not immediately obvious to you on a marketing web site
> does not mean it isn't there. You'll find it in our repo too (though
> not as a git repository which is actually what people want).
> Saying that, I have no objection at all to making this more obvious,
> and will do so. We're proud of what we do with open source.

Well, I spent more time than "immediate" to try to find them and if it's not 
obvious where they are or they aren't linked to, then they might as well not be 
there tbh.

so where is this publically available repo?

>>  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.
> We use a distribution version (we run Ubuntu throughout). I'm not
> quite sure why it's an unfair comparison. If there was an Ubuntu version
> of 4.2.x for an LTS release, we'd be using that.
> Are you implying that the STABLE Xen version on xenbits should not be
> expected to be as reliable as the same version packaged by a maintainer?
> If so, why?

I seem to remember that a (perhaps old) Xen mantra was that it is a project and 
not a product. Ubuntu is a product, Xen is a project. RedHat 5 is a product and 
I seem to remember Xen being stable for my limited purposes. Your experience 
may have differed.

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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.