> -----Original Message----- > From: intel-gfx-bounces+gordon.jin=intel.com at lists.freedesktop.org > [mailto:intel-gfx-bounces+gordon.jin=intel.com at lists.freedesktop.org] On > Behalf Of Alan W. Irwin > Sent: Sunday, January 22, 2012 3:45 AM > To: Daniel Vetter > Cc: Intel Graphics Development > Subject: Re: Updated -next > > On 2012-01-21 15:12+0100 Daniel Vetter wrote: > > > drm-intel-testing is drm-intel-next and drm-intel-fixes merged together > > (as the time of when I've pushed things out). Gordon Jin said that he > > prefers to qa one single branch and that qa will take the job of finding > > out whether an issue has been introduced in -fixes or in -next. I agree > > that it makes more sense to test everything together, otherwise you'll > > miss some of the bugfixes in -fixes. > > As an Intel graphics user whose number-one concern is stability, I > have to make a comment here. I fully appreciate that the top priority > for qa should be the cutting edge so that Intel developers get quick > feedback on their changes. But that leaves the -fixes branch untested > _on its own_ by qa, and I urge Gordon Jin to rethink that decision. (sorry for the late reply as I just came back from vacation) QA testing against -fixes is unchanged, i.e. running automated tests (like intel-gpu-tools) nightly, and running more manual tests in release cycle. We call it "stable build", together with release branch of other components (like mesa 8.0 branch). The testing against "unstable build" (cutting edge code, consisting of master branch of components, like mesa master branch, and -next/-testing for kernel) is also unchanged (automated nightly testing + manual). The only thing noticeable in this transition is I suggested -next (continue) to be super-set of -fixes, to make sure the critical fixes in -fixes also included in -next, and also the expensive manual testing against -next partly covers -fixes. Thus Daniel created -testing to meet my requirement. Hope this clarifies. Thanks Gordon
