[Gluster-devel] How to cope with spurious regression failures

Raghavendra Talur rtalur at redhat.com
Thu Mar 3 01:42:13 UTC 2016


On Wed, Feb 10, 2016 at 8:29 PM, Emmanuel Dreyfus <manu at netbsd.org> wrote:

> On Wed, Feb 10, 2016 at 07:30:24PM +0530, Raghavendra Talur wrote:
> > Any comments before I merge the patch
> http://review.gluster.org/#/c/13393/ ?
>
> The proposal has the merit of adressing the multi-OS case, but fails
> to address future OS addition. If it does not matter to change the
> naming the day we add another OS, it is fine for me. Otherwise, I
> adivse using a 8 bit hex value that will be fine for a long time:
>
> K01-test.t kills for Linux
> K02-test.t kills for NetBSD
> K03-test.t kills for both Linux and NetBSD
> K04-test.t kills for new OS 1 we would add later.
> K08-test.t kills for new OS 2 we would add later.
> K10-test.t kills for new OS 3 we would add later.
> K19-tets.t kills for Linux, new OS 2 and new OS 3...
>
> Of course if we add more than 8 OS in regression that is not enough,
> but you can start with a 16 bit value if you prefer :-)
>
>
OK, I have updated the patch and replied to Manu's question and Jeff's
question on the patch itself.
The tests passed on the first run itself, except for the NetBSD with
"another test running on slave" error.
I consider passing on first run itself as a great improvement compared to
our current state.

Please review the patch: http://review.gluster.org/#/c/13393/

--
> Emmanuel Dreyfus
> manu at netbsd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160303/6477e256/attachment-0001.html>


More information about the Gluster-devel mailing list