Re: How to cope with spurious regression failures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Feb 10, 2016 at 8:29 PM, Emmanuel Dreyfus <manu@xxxxxxxxxx> 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@xxxxxxxxxx

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux