I think not having NetBSD runs for every patch will introduce new set of
problems, like
- who will debug the nightly failures?
- If NetBSD failures queued up everyday, then how to address those
issues
- Additional overhead to identify which patch caused nightly build
failure
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?
I agree.
Regards,
Nithya
- Original Message -
> From: "Atin Mukherjee"
> To: "Joseph Fernandes" , "Avra Sengupta"
>
> Cc: "Gluster Devel" , "gluster-infra"
>
> Sent:
On 01/07/2016 03:52 PM, Raghavendra Gowdappa wrote:
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?
It failed with EIO.
mount_nfs: can't access /patchy: Permission denied
mount_nfs:
Jeff Darcy wrote:
> I'd prefer a "defined level of effort" approach which *might* reduce the
> benefit we derive from NetBSD testing but *definitely* keeps the cost
> under control.
Did we identify the worst offenders within the spurious failing tests?
We could ignore their
Kaleb KEITHLEY writes:
> On 01/07/2016 08:47 AM, Jeff Darcy wrote:
I am not that big a fan of portable software development at all- more
so for system software.
>>>
>>> This can be discussed for server side, but for client side, making
>>> glusterfs linux-only
On 01/07/2016 07:24 PM, Jeff Darcy wrote:
I'd prefer a "defined level of effort" approach which *might* reduce the
benefit we derive from NetBSD testing but *definitely* keeps the cost
under control.
Did we identify the worst offenders within the spurious failing tests?
We could ignore their
Jeff Darcy wrote:
> > Now what is the policy on post-merge regression failure? What happens
> > if original submitter is now willing to investigate?
>
> Then regressions will continue to fail on NetBSD, as they do now, but
> without impacting work on other platforms.
Well
Sorry for the delayed reply. Had missed out this mail. Please find my
comments inlined.
On Thu, Dec 31, 2015 at 4:56 AM, Rick Macklem wrote:
> Jordan Hubbard wrote:
> >
> > > On Dec 30, 2015, at 2:31 AM, Niels de Vos wrote:
> > >
> > >> I'm guessing
+sakshi.
On Fri, Jan 8, 2016 at 10:16 AM, Raghavendra G
wrote:
> Sakshi is looking into this.
>
> @Sakshi,
>
> Please update your progress on this thread.
>
> regards,
>
> On Thu, Jan 7, 2016 at 6:39 AM, Vijay Bellur wrote:
>
>> On 01/06/2016 01:55
On 01/08/2016 09:57 AM, Emmanuel Dreyfus wrote:
I am a bit disturbed by the fact that people raise the
"NetBSD regression ruins my life" issue without doing the work of
listing the actual issues encountered.
I already did earlier- the lack of infrastructure to even find out what
caused the
Ravishankar N wrote:
> > I am a bit disturbed by the fact that people raise the
> > "NetBSD regression ruins my life" issue without doing the work of
> > listing the actual issues encountered.
> I already did earlier- the lack of infrastructure to even find out what
>
Sakshi is looking into this.
@Sakshi,
Please update your progress on this thread.
regards,
On Thu, Jan 7, 2016 at 6:39 AM, Vijay Bellur wrote:
> On 01/06/2016 01:55 AM, Rajesh Joseph wrote:
>
>> Yesterday, I looked into the core. From the core it looked like the
>>
The crash seems to happen in the function glusterfs_rebalance_event_notify_cbk
since the frame is corrupted. I guess frame got corrupted
since the calling function glusterfs_rebalance_event_notify seems to
immediately call STACK_DESTROY after calling the cbk.
I ran the snapshot test to check,
Top posting, this is a very old thread.
Keeping in view the recent NetBSD problems and the number of bugs creeping
in, I suggest we do these things right now:
a. Change the gerrit merge type to fast forward only.
As explained below in the thread, with our current setup even if both
PatchA and
On Fri, Jan 8, 2016 at 12:10 PM, Kaushal M wrote:
> On Fri, Jan 8, 2016 at 12:03 PM, Raghavendra Talur wrote:
>> Top posting, this is a very old thread.
>>
>> Keeping in view the recent NetBSD problems and the number of bugs creeping
>> in, I suggest we do
On Fri, Jan 8, 2016 at 12:28 PM, Kaushal M wrote:
> On Fri, Jan 8, 2016 at 12:10 PM, Kaushal M wrote:
> > On Fri, Jan 8, 2016 at 12:03 PM, Raghavendra Talur
> wrote:
> >> Top posting, this is a very old thread.
> >>
> >> Keeping in
> 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
- Original Message -
> From: "Pranith Kumar Karampuri"
> To: "Emmanuel Dreyfus" , "Ravishankar N"
>
> Cc: "Gluster Devel" , "gluster-infra"
>
> Sent: Friday, January 8,
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
On Fri, Jan 8, 2016 at 12:03 PM, Raghavendra Talur wrote:
> Top posting, this is a very old thread.
>
> Keeping in view the recent NetBSD problems and the number of bugs creeping
> in, I suggest we do these things right now:
>
> a. Change the gerrit merge type to fast forward
On 01/07/2016 02:24 PM, Emmanuel Dreyfus wrote:
> Kaleb KEITHLEY wrote:
>
>> I was in the middle of composing a reply along pretty much the same
>> lines when I saw Jeff's reply land in my inbox.
>>
>> We are migrating from gnfs to NFS-Ganesha for NFS; NFS-Ganesha uses
>>
Avra Sengupta wrote:
> Agree with your point. If we are ready to make exceptions, then we might
> as well not block all the patches. As Jeff suggested, triaging the
> nightly/weekly results manually and making any serious issues a blocker
> should suffice.
How are you
> How are you going to make a serious issue a blocker?
We can turn off the "merge" button at any time, by either technical or
social means. The "how" is easy; it's the "when" that's fraught with
controversy.
> If we go that way, we need to run a regression for each merged patch,
> which will be
On Wed, Dec 30, 2015 at 09:00:32AM -0500, Rick Macklem wrote:
> Niels de Vos wrote:
> > On Tue, Dec 29, 2015 at 08:12:40PM -0500, Rick Macklem wrote:
> > > Hi,
> > >
> > > I'm been playing with the FreeBSD port of GlusterFS and it seems
> > > to be working ok. I do notice that the daemons use a
Kaleb KEITHLEY wrote:
> I was in the middle of composing a reply along pretty much the same
> lines when I saw Jeff's reply land in my inbox.
>
> We are migrating from gnfs to NFS-Ganesha for NFS; NFS-Ganesha uses
> GFAPI. If Samba isn't already using a GFAPI-based VFS, it
26 matches
Mail list logo