----- Original Message ----- > From: "Ravishankar N" <ravishankar@xxxxxxxxxx> > To: "Emmanuel Dreyfus" <manu@xxxxxxxxxx> > Cc: "gluster-infra" <gluster-infra@xxxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Thursday, January 7, 2016 3:14:12 PM > Subject: Re: NetBSD tests not running to completion. > > 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. Did the test fail (with an error)? or was it hung? > > 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 > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
