On 01/07/2016 02:39 PM, Emmanuel Dreyfus wrote:
On Wed, Jan 06, 2016 at 05:49:04PM +0530, Ravishankar N wrote:
I re triggered NetBSD regressions for http://review.gluster.org/#/c/13041/3
but they are being run in silent mode and are not completing. Can some one
from the infra-team take a look? The last 22 tests in
https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/ have
failed. Highly unlikely that something is wrong with all those patches.
I note your latest test compelted with an error in mount-nfs-auth.t:
https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13260/consoleFull
Yes, the test that failed is "dd if=/dev/zero of=$N0/test-big-write
count=500 bs=1024k"
I don't know why.
Would you have the jenkins build that did not complete s that I can have a
look at it?
Unfortunately I did not save the link.
Generally speaking, I have to pôint that NetBSD regression does show light
on generic bugs, we had a recent exemple with quota-nfs.t. For now there
are not other well supported platforms, but if you want glusterfs to
be really portable, removing mandatory NetBSD regression is not a good idea:
portability bugs will crop.
This is all IMHO:
I am not that big a fan of portable software development at all- more
so for system software. Maybe it is a thing in desktop application
development world . Even in a recent RFE on gluster-devel for
eventing-framework I saw that systemd and dbus APIs are considered
because they are Linux specific. To me that is a silly reason to
reinvent the wheel. I'd rather that the software sticks to one platform
and build on whatever the platform has to offer than attempting to run
on all OSes.
Even a daily or weekly regression run seems a bad idea to me. If you do not
prevent integration of patches that break NetBSD regression, that will get
in, and tests will break one by one over time. I have a first hand
experience of this situation, when I was actually trying to catch on with
NetBSD regression. Many time I reached something reliable enough to become
mandatory, and got broken by a new patch before it became actualy mandatory.
IMO, relaxing NetBSD regression requirement means the project drops the goal
of being portable.
It is not the failure of regressions that bother me. It is the lack of
infrastructure to debug failures that is irritating. If Linux
regressions fail, I can just run it in my laptop and figure things out
.For NetBSD, I'd have to take a slave offline. Then I have to send a
mail about it and hope that every one has seen it and does not
accidentally use the system while I'm debugging. Then there's this part
where none of the bash/gdb/whatever-debugging-tools in Linux that you
are used to will work on NetBSD. Like I pointed out in another thread,
at least a VM image for NetBSD that I can run on my laptop would be
beneficial to a big extent.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
