Re: Testing the kernels

[Jeremy Fitzhardinge <jeremy@goop.org>]

 On 08/31/2010 08:06 AM, Ian Jackson wrote:
> Jeremy Fitzhardinge writes ("[Xen-devel] Testing the kernels"):
>> I think you should use "xen/next-2.6.32" as the input to the test
>> subsystem.  If you have a git tree on xenbits with a, say,
>> "xen/tested-2.6.32" branch which gets updated when the tests pass,
> I have done roughly this.  It seems to be mostly working[1] after I
> told it to do some tests over the weekend, so I've reenabled it for
> emailing to the list.
>
> [1] When I say working I mean that the test system is functioning
> properly.  Unfortunately many of the tests themselves are failing.

Regressions?

> The tested tree is:
>   http://xenbits.xensource.com/gitweb?p=linux-pvops.git;a=summary
>   git://xenbits.xensource.com/linux-pvops.git
> branch "master".
>
> I can switch the tester's input at will.  Can you promise that when we
> do that, all updates will be fast forwards, so that the tested output
> branch is always fast forwarding ?

Sure.

>>  then I can make that automatically update xen/stable-2.6.32.x for
>> public consumption.
> Can this be done in a way that doesn't involve waiting for you ?  The
> testing system obviously pushes automatically and it would be good to
> publish those things in the right places without further manual
> intervention.

Yes.  I was planning on setting up a cronjob on kernel.org to update the
branch once we'd sorted out all the details.

> Also, you'll see that I chose a single branch name "master" rather
> than encoding the kernel version number.  This is because I think we
> should have one branch tested like this, rather than a separate branch
> for each kernel version.
>
> When we update the kernel version we intend to use, this should be a
> fast forward update and gated though the testing in the ordinary way,
> so it should update the same tag.  Do you agree ?

Hm. I was hoping at some point to have two kernels going through
testing.  We're planning on supporting 2.6.32 for a long time, so we
should keep testing that.  But I'd also like to start tracking upstream
more closely (starting with .36) which we should also test.

    J