[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] S3 is broken again in xen-unstable
>>> On 29.04.13 at 12:55, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote: > On Mon, Apr 29, 2013 at 9:45 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>>> On 25.04.13 at 14:00, Ben Guthro <ben@xxxxxxxxxx> wrote: >>> I don't have time to bisect this, currently - but just thought I'd let >>> the list know that, while xen-4.2 works (with the recent S3 changes >>> I've submitted) - 4.3 is broken again. >>> >>> I'm not sure if it is the hypervisor, or the kernel, since I upgraded >>> both in my "unstable" build environment. >>> >>> Since this is something that XenClient really relies on working, it >>> has been a pain point with every upgrade of Xen for us. >> >> Perhaps one point here also is that you upgrade in too big steps? >> >> More regular participation in development and patch review >> would very likely also help keeping down the number of >> regressions here. > > Perhaps, but given the incredible amounts of traffic on the list, how > is he supposed to know which patches might break suspend or not? And > even if he did, he would have to take the time to understand every > single hypervisor patch and predict how it would act on suspend, which > is just not reasonable. Remember we're on the other side of this > equation wrt Linux -- it's all to easy for someone to move something > apparently innocuous around and have it break dom0 pvops in a way > that's not noticed until 6 months later. That's why we do regular > testing of Linus' tree, as well as Ingo's x86 tree. > > The right thing to do is to put at least a basic suspend test into the > testing push-gate, so that when someone submits a change that breaks > suspend, *they* are the ones that have to figure out what went wrong > and fix it. I was in no way suggesting this to be a bad idea. What I was trying to point out is that testing a certain feature only every couple of major releases is very likely to not nearly help as much as being involved regularly. And no, I also didn't mean to suggest for _anyone_ to review each and every individual patch. But looking at some key ones before they go in would certainly help. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |