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

Re: [Xen-devel] blktap, qdisk, xl cd-eject, and xencommons



>>> On 30.04.13 at 14:16, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 04/30/2013 12:54 PM, Wei Liu wrote:
>> On Tue, Apr 30, 2013 at 11:56:35AM +0100, George Dunlap wrote:
>> [...]
>>>
>>> Well we didn't have that before 4.3, and it didn't seem to be a major
>>                                    4.2 maybe?
>>> problem; I think people just knew to make sure blktap got modprobed
>>> themselves.  So I wouldn't personally consider this a blocker -- but I'm
>>> still open to other ideas.
>>>
>>> In any case, it would certainly be *better* if we can have libxl attempt
>>> a modprobe, so if we can get it in before the release, I think that
>>> would be a good thing.
>>>
>>
>> So now the libxl infrastructure is no longer a blocker, good. Then how
>> can we justify it if we need it to go in at this stage? We're
>> approaching RC1 next week, what is the suitable policy for this
>> infrastructure?
> 
> Well most of those things are "guidelines" rather than rules. :-)  Not 
> everything fits neatly into the packages.  In this case, this is a mild 
> regression from 4.2 -- so it could be sort of considered a "bug fix".
> 
> OTOH, if Jan were willing, the lowest disturbance thing to do might be 
> to leave the modprobe in, and promise to address the issue first thing 
> in the 4.4.  (In that case I'd owe Jan a big apology, as it was I that 
> promised to sort it out for 4.3.)

If this turns too intrusive at this point I wouldn't heavily object,
but would raise the question of what if the same happens during
the 4.4 cycle again.

Jan


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


 


Rackspace

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