On 02/10/2016 02:13 AM, Justin Pettit wrote:
>
>> On Feb 8, 2016, at 5:38 PM, Russell Bryant wrote:
>>
>> Somewhat related - I'd like to be more proactive at keeping an eye on
>> travis-ci failures. I just signed up for the build mailing list. It
>> looks like travis-ci is configured to post th
> On Feb 8, 2016, at 5:38 PM, Russell Bryant wrote:
>
> Somewhat related - I'd like to be more proactive at keeping an eye on
> travis-ci failures. I just signed up for the build mailing list. It
> looks like travis-ci is configured to post there, but I don't see any
> posts from travis-ci on
> On Feb 8, 2016, at 5:38 PM, Russell Bryant wrote:
>
> On 02/08/2016 06:18 PM, Justin Pettit wrote:
>>
>> The "shame" comment was meant tongue-in-cheek, but I didn't want to
>> overwhelm the message with smiley faces. Sorry that didn't come
>> through.
>
> Ah, well I'm sorry too. You had in
On 02/08/2016 06:18 PM, Justin Pettit wrote:
>
>> On Feb 8, 2016, at 10:54 AM, Russell Bryant wrote:
>>
>> On 02/08/2016 01:03 PM, Justin Pettit wrote:
>>
>> There are solutions to this problem, but it requires letting a CI system
>> do the merging of patches for you.
>>
>>> The Linux kernel does
> On Feb 8, 2016, at 10:54 AM, Russell Bryant wrote:
>
> On 02/08/2016 01:03 PM, Justin Pettit wrote:
>
> There are solutions to this problem, but it requires letting a CI system
> do the merging of patches for you.
>
>> The Linux kernel does something similar.
>> Shame is often a good motivat
On 02/08/2016 01:03 PM, Justin Pettit wrote:
>
>> On Feb 8, 2016, at 9:34 AM, Kavanagh, Mark B
>> wrote:
>>
>>> I think the example that you show is actually a pretty good example of
>>> how quickly we catch problems.
>>
>> Sure. At the same time though, this is a reactive approach, rather than
> On Feb 8, 2016, at 9:34 AM, Kavanagh, Mark B
> wrote:
>
>> I think the example that you show is actually a pretty good example of
>> how quickly we catch problems.
>
> Sure. At the same time though, this is a reactive approach, rather than a
> proactive one, which inevitably results in more
>
>On Mon, Jan 25, 2016 at 03:15:23PM +, Mark Kavanagh wrote:
>> Current testing guidelines do not take account of two distinct
>> OVS builds:
>>a) 'standard' OVS
>>b) OVS with DPDK integration
>>
>> It is critical that all patches are tested against both builds; if not,
>> there is a s
On Mon, Jan 25, 2016 at 03:15:23PM +, Mark Kavanagh wrote:
> Current testing guidelines do not take account of two distinct
> OVS builds:
>a) 'standard' OVS
>b) OVS with DPDK integration
>
> It is critical that all patches are tested against both builds; if not,
> there is a strong pos
Current testing guidelines do not take account of two distinct
OVS builds:
a) 'standard' OVS
b) OVS with DPDK integration
It is critical that all patches are tested against both builds; if not,
there is a strong possibility that code which adversely affects one
of the builds may be upstreame
10 matches
Mail list logo
