On Mon, 18 May 2015, George Dunlap wrote:
> On 05/18/2015 12:21 PM, Ian Campbell wrote:
> > On Mon, 2015-05-18 at 11:54 +0100, George Dunlap wrote:
> >> On 05/18/2015 11:33 AM, Ian Campbell wrote:
> >>> On Mon, 2015-05-18 at 11:08 +0100, George Dunlap wrote:
> On Wed, May 13, 2015 at 12:48 PM,
On Mon, 2015-05-18 at 14:33 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v4] OSSTEST: introduce a raisin
> build test"):
> > On Mon, 2015-05-18 at 14:05 +0100, George Dunlap wrote:
> > > That solves the most general case; but it sounds l
Ian Campbell writes ("Re: [Xen-devel] [PATCH v4] OSSTEST: introduce a raisin
build test"):
> On Mon, 2015-05-18 at 14:05 +0100, George Dunlap wrote:
> > That solves the most general case; but it sounds like you care mostly
> > about the very specific case of dealing with
On Mon, 2015-05-18 at 14:23 +0100, George Dunlap wrote:
> On 05/18/2015 02:14 PM, Ian Campbell wrote:
> >> That solves the most general case; but it sounds like you care mostly
> >> about the very specific case of dealing with components that depend on
> >> the current output of xen.git. Starting
On 05/18/2015 02:14 PM, Ian Campbell wrote:
>> That solves the most general case; but it sounds like you care mostly
>> about the very specific case of dealing with components that depend on
>> the current output of xen.git. Starting simple may be fine.
>
> Currently we only have ts-*-build thing
On Mon, 2015-05-18 at 14:05 +0100, George Dunlap wrote:
> It sounds like you're saying just to have a "base Xen" build that would
> build what currently comes out of xen.git, and then base our other
> components on top of that.
Correct, otherwise you get one big job which can fail due to any
compo
On 05/18/2015 12:21 PM, Ian Campbell wrote:
> On Mon, 2015-05-18 at 11:54 +0100, George Dunlap wrote:
>> On 05/18/2015 11:33 AM, Ian Campbell wrote:
>>> On Mon, 2015-05-18 at 11:08 +0100, George Dunlap wrote:
On Wed, May 13, 2015 at 12:48 PM, Stefano Stabellini
wrote:
> On Wed, 13 Ma
On Mon, 2015-05-18 at 11:08 +0100, George Dunlap wrote:
> On Wed, May 13, 2015 at 12:48 PM, Stefano Stabellini
> wrote:
> > On Wed, 13 May 2015, Ian Campbell wrote:
> >> On Tue, 2015-05-12 at 12:46 +0100, Stefano Stabellini wrote:
> >> > > Would a separate clone of the same raisin version with som
On Wed, May 13, 2015 at 12:48 PM, Stefano Stabellini
wrote:
> On Wed, 13 May 2015, Ian Campbell wrote:
>> On Tue, 2015-05-12 at 12:46 +0100, Stefano Stabellini wrote:
>> > > Would a separate clone of the same raisin version with some sort of
>> > > "dist" directory transported over be sufficient a
On Mon, 2015-05-18 at 11:54 +0100, George Dunlap wrote:
> On 05/18/2015 11:33 AM, Ian Campbell wrote:
> > On Mon, 2015-05-18 at 11:08 +0100, George Dunlap wrote:
> >> On Wed, May 13, 2015 at 12:48 PM, Stefano Stabellini
> >> wrote:
> >>> On Wed, 13 May 2015, Ian Campbell wrote:
> On Tue, 2015
On 05/18/2015 11:33 AM, Ian Campbell wrote:
> On Mon, 2015-05-18 at 11:08 +0100, George Dunlap wrote:
>> On Wed, May 13, 2015 at 12:48 PM, Stefano Stabellini
>> wrote:
>>> On Wed, 13 May 2015, Ian Campbell wrote:
On Tue, 2015-05-12 at 12:46 +0100, Stefano Stabellini wrote:
>> Would a sepa
On Wed, 2015-05-13 at 12:48 +0100, Stefano Stabellini wrote:
> On Wed, 13 May 2015, Ian Campbell wrote:
> > On Tue, 2015-05-12 at 12:46 +0100, Stefano Stabellini wrote:
> > > > Would a separate clone of the same raisin version with some sort of
> > > > "dist" directory transported over be sufficien
On Wed, 13 May 2015, Ian Campbell wrote:
> On Tue, 2015-05-12 at 12:46 +0100, Stefano Stabellini wrote:
> > > Would a separate clone of the same raisin version with some sort of
> > > "dist" directory transported over be sufficient and supportable? Or are
> > > raisin's outputs not in one place and
On Tue, 2015-05-12 at 12:46 +0100, Stefano Stabellini wrote:
> > Would a separate clone of the same raisin version with some sort of
> > "dist" directory transported over be sufficient and supportable? Or are
> > raisin's outputs not in one place and easily transportable?
> >
> > i.e. today build-$
On Tue, 12 May 2015, Ian Campbell wrote:
> On Tue, 2015-05-12 at 12:20 +0100, Stefano Stabellini wrote:
>
> > > We currently have build jobs for both normal and the XSM case.
> > > Duplicating the raisin jobs is also going to duplicate the build for
> > > everything else it builds, which might be
On Tue, 2015-05-12 at 12:20 +0100, Stefano Stabellini wrote:
> > We currently have build jobs for both normal and the XSM case.
> > Duplicating the raisin jobs is also going to duplicate the build for
> > everything else it builds, which might be wasteful?
>
> We could disable the raisin build if
On Tue, 12 May 2015, Ian Campbell wrote:
> On Tue, 2015-05-12 at 10:20 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> >
> > Changes in v4:
> > - introduce enable_raisin in mfi-common: only build raisin when building
> > xen-unstable
> > - start off from the
Ian Campbell writes ("Re: [PATCH v4] OSSTEST: introduce a raisin build test"):
> More generally this now ties everything together into one build job.
I hadn't spotted that.
I think this is very undesirable.
> Currently while bisecting osstest can try and reuse e.g. the xen job
> with a different
On Tue, 2015-05-12 at 10:20 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
>
> ---
>
> Changes in v4:
> - introduce enable_raisin in mfi-common: only build raisin when building
> xen-unstable
> - start off from the default raisin config, then append osstest config
> options
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- introduce enable_raisin in mfi-common: only build raisin when building
xen-unstable
- start off from the default raisin config, then append osstest config
options to it
- do not write variable to the raisin config if the conrresponding
runva
20 matches
Mail list logo
