Testing the kernels

Testing the kernels

[Jeremy Fitzhardinge]

 So as we discussed, we should split the testing of the toolstack and
the kernel into separate pieces so that kernel failures don't prevent
the toolstack tree from being updated.

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, then
I can make that automatically update xen/stable-2.6.32.x for public
consumption.

That way people who need/want bleeding edge changes can use
xen/next-2.6.32, and everyone else gets xen/stable-2.6.32.x by default.

    J

Re: Testing the kernels

[Ian Jackson]

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.

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 ?

>  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.

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 ?

Ian.

Re: Testing the kernels

[Jeremy Fitzhardinge]

 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

Re: Testing the kernels

[Ian Jackson]

Jeremy Fitzhardinge writes ("Re: [Xen-devel] Testing the kernels"):
> Regressions?

Well, not really regressions in the view of the testing system,
because the "tested" kernel tree was only just created so has all the
failures, and xen-unstable was pushed manually recently.

> > 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.

OK.  I can arrange to prod some script of yours if you prefer.

> > 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.

OK, I guess I could have a different branch for my testing which
tracks a different branch of yours.  I've called this one "linux",
as in
  Subject: [linux test] 2057: tolerable FAIL - PUSHED
but perhaps I should rename it ?

Ian.

Re: Testing the kernels

[Pasi Kärkkäinen]

On Tue, Aug 31, 2010 at 06:54:18PM +0100, Ian Jackson wrote:
> Jeremy Fitzhardinge writes ("Re: [Xen-devel] Testing the kernels"):
> > Regressions?
> 
> Well, not really regressions in the view of the testing system,
> because the "tested" kernel tree was only just created so has all the
> failures, and xen-unstable was pushed manually recently.
> 
> > > 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.
> 
> OK.  I can arrange to prod some script of yours if you prefer.
> 
> > > 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.
> 
> OK, I guess I could have a different branch for my testing which
> tracks a different branch of yours.  I've called this one "linux",
> as in
>   Subject: [linux test] 2057: tolerable FAIL - PUSHED
> but perhaps I should rename it ?
> 

If it's 2.6.32.x I guess it should say linux-2.6.32.x ? 

-- Pasi