[Gluster-devel] [Gluster-infra] NetBSD tests not running to completion.

[Avra Sengupta]

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
>
> Would you have the jenkins build that did not complete s that I can have a
> look at it?
>
> 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.
>
> 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.
Why is this a bad idea? This approach seems to be the middle ground 
between, not accepting any patches because of netbsd regressions 
failing, and totally removing the mandate of having NetBSD regressions 
passing. It isn't going to be any different than it is today, just that 
a weekly regression will help concentrate our efforts(in debugging the 
issues reposrted by NetBSD regression) and allow us to be more 
productive. It's a simple matter of assigning ownership of triaging the 
regressions to people who own the particuar testcases that fail the 
regression.

All the time that is spent on monitoring patches, and re-trigerring 
regressions can be spent elsewhere. Also as a project we need to decide, 
if relaxing a few requirements can reduce the turn around time between a 
patch being posted upstream, and the patch being merged, without 
actually affecting portability, then what reason do we have for not 
pursuing such an approach.
>   
>
> IMO, relaxing NetBSD regression requirement means the project drops the goal
> of being portable.
>