[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |