Re: [Gluster-devel] [Gluster-infra] NetBSD tests not running to completion.
On 01/11/2016 01:00 PM, Pranith Kumar Karampuri wrote: On 01/09/2016 12:34 AM, Vijay Bellur wrote: On 01/08/2016 08:18 AM, Jeff Darcy wrote: I think we just need to come up with rules for considering a platform to have voting ability before merging the patch. I totally agree, except for the "just" part. ;) IMO a platform is much like a feature in terms of requiring commitment/accountability, community agreement on cost/benefit, and so on. You can see a lot of that in the feature-page template. https://github.com/gluster/glusterfs-specs/blob/master/in_progress/template.md That might provide a good starting point, even though some items won't apply to a platform and others are surely missing. It's new territory, after all. Also, I believe the bar for platforms should be higher than for features, because a new platform multiplies our test load (and associated burdens) instead of merely adding to it. Also, new features rarely impact all developers the way that new platforms do. Nobody should be making assumptions or unilateral decisions about something as important as when it is or is not OK to block all merges throughout the project. That needs to be the subject of an explicit and carefully considered community decision. That, in turn, requires some clearly defined cost/benefit analysis and resource commitment. If we don't get the process right this time, we'll end up having this same conversation yet again, and I'm sure nobody wants that. Agree here. Pranith - can you please help come up with a governance process for platforms in consultation with Jeff and Emmanuel? Once it is ready we can propose that in the broader community and formalize it. Sent the following rfc patch which will be updated based on the discussions. http://review.gluster.org/13211 I left the decisions we need to come up with as TBD in the sections. Please feel free to suggest what you would like to see there as comments on the patch. If we need more sections that we need to consider, let us add them as comments too. I will periodically refresh the patch based on the decisions that are agreed upon. + All the people who responded on the thread. Please update the patch with your suggestions. Pranith I hope the discussion will come to natural conclusions based on the discussions there. Thanks Pranith Thanks, Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] NetBSD tests not running to completion.
On 01/09/2016 12:34 AM, Vijay Bellur wrote: On 01/08/2016 08:18 AM, Jeff Darcy wrote: I think we just need to come up with rules for considering a platform to have voting ability before merging the patch. I totally agree, except for the "just" part. ;) IMO a platform is much like a feature in terms of requiring commitment/accountability, community agreement on cost/benefit, and so on. You can see a lot of that in the feature-page template. https://github.com/gluster/glusterfs-specs/blob/master/in_progress/template.md That might provide a good starting point, even though some items won't apply to a platform and others are surely missing. It's new territory, after all. Also, I believe the bar for platforms should be higher than for features, because a new platform multiplies our test load (and associated burdens) instead of merely adding to it. Also, new features rarely impact all developers the way that new platforms do. Nobody should be making assumptions or unilateral decisions about something as important as when it is or is not OK to block all merges throughout the project. That needs to be the subject of an explicit and carefully considered community decision. That, in turn, requires some clearly defined cost/benefit analysis and resource commitment. If we don't get the process right this time, we'll end up having this same conversation yet again, and I'm sure nobody wants that. Agree here. Pranith - can you please help come up with a governance process for platforms in consultation with Jeff and Emmanuel? Once it is ready we can propose that in the broader community and formalize it. Sent the following rfc patch which will be updated based on the discussions. http://review.gluster.org/13211 I left the decisions we need to come up with as TBD in the sections. Please feel free to suggest what you would like to see there as comments on the patch. If we need more sections that we need to consider, let us add them as comments too. I will periodically refresh the patch based on the decisions that are agreed upon. I hope the discussion will come to natural conclusions based on the discussions there. Thanks Pranith Thanks, Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] NetBSD tests not running to completion.
On 01/08/2016 08:18 AM, Jeff Darcy wrote: I think we just need to come up with rules for considering a platform to have voting ability before merging the patch. I totally agree, except for the "just" part. ;) IMO a platform is much like a feature in terms of requiring commitment/accountability, community agreement on cost/benefit, and so on. You can see a lot of that in the feature-page template. https://github.com/gluster/glusterfs-specs/blob/master/in_progress/template.md That might provide a good starting point, even though some items won't apply to a platform and others are surely missing. It's new territory, after all. Also, I believe the bar for platforms should be higher than for features, because a new platform multiplies our test load (and associated burdens) instead of merely adding to it. Also, new features rarely impact all developers the way that new platforms do. Nobody should be making assumptions or unilateral decisions about something as important as when it is or is not OK to block all merges throughout the project. That needs to be the subject of an explicit and carefully considered community decision. That, in turn, requires some clearly defined cost/benefit analysis and resource commitment. If we don't get the process right this time, we'll end up having this same conversation yet again, and I'm sure nobody wants that. Agree here. Pranith - can you please help come up with a governance process for platforms in consultation with Jeff and Emmanuel? Once it is ready we can propose that in the broader community and formalize it. Thanks, Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] NetBSD tests not running to completion.
As Avra mentioned we should trigger regressions for pathces which got +2. That would save lot of regression cycles. Thanks and Regards, Kotresh H R - Original Message - > From: "Aravinda" > To: "Atin Mukherjee" , "Joseph Fernandes" > , "Avra Sengupta" > > Cc: "gluster-infra" , "Gluster Devel" > > Sent: Thursday, January 7, 2016 2:50:17 PM > Subject: Re: [Gluster-devel] [Gluster-infra] NetBSD tests not running to > completion. > > 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 > > regards > Aravinda > > On 01/07/2016 01:53 PM, Atin Mukherjee wrote: > > I have been always with this approach right from the beginning. We can > > definitely have nightly if not weekly NetBSD regressions to sanitize the > > changes, with that model we wouldn't need to eliminate BSD support but > > we can avoid this hard dependency in patch acceptance which has haunted > > us *multiple* times now. > > > > Thanks, > > Atin > > > > On 01/07/2016 12:38 PM, Joseph Fernandes wrote: > >> +2 Avra > >> > >> - Original Message - > >> From: "Avra Sengupta" > >> To: "Gluster Devel" , "gluster-infra" > >> > >> Sent: Thursday, January 7, 2016 11:51:51 AM > >> Subject: Re: [Gluster-infra] [Gluster-devel] NetBSD tests not running to > >>completion. > >> > >> The same issue keeps coming up every few months, where all patch > >> acceptances comes to a grinding halt with a dependency on NetBSD > >> regressions. I have been re-trigerring my patches too, and they are not > >> completing. Not to mention the long wait queue for them to run in the > >> first place and then having them not complete. > >> > >> I know this issue has been discussed many times before and every time we > >> have arrived at the conclusion that we need to have more stable tests, > >> or a more robust infrastructure, but there's more to it than that. > >> Here's listing down a few of the things I have observed: > >> 1. Not many people are well versed with debugging the issues, that > >> result in failure in NetBSD regression suites, simply because not many > >> of us are familiar with the nuances of the platform. > >> 2. If I am a developer interested in being a part of the gluster > >> community and contributing code to it, the patches I send will have > >> dependency on NetBSD regressions. When people who have been contributing > >> for years now are finding it cumbersome to have the NetBSD regressions > >> pass for their patches, imagine the impression and the impact on > >> motivation it will have on a new developer. We need to ask ourselves how > >> is this impacting a patch acceptance process. > >> > >> We can atleast try a different approaches to tackle this problem instead > >> of just waiting for the test suite to stabilize or the infrastructure to > >> get better. > >> 1. We can have NetBSD as a separate port, and not have patches sent to > >> the master branch be dependent on it's regression. > >> 2. We can also have a nightly NetBSD regression run, instead of running > >> it per patch. If a particular regression test fails, the owner of the > >> test looks into it, and we debug the issue. One might say it's just > >> delaying the problem, but atleast we will not have all patches > >> acceptances blocked. > >> 3. We really need to trigger regressions only on the patches that have > >> been reviewed and have gotten a +2. This will substantially bring down > >> the wait time. I remember Atin bringing this up a few months back, but > >> it still hasn't been implemented. Can we please have this ASAP. > >> > >> Regards, > >> Avra > >> > >> On 01/06/2016 05:49 PM, 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
Re: [Gluster-devel] [Gluster-infra] 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 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. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] NetBSD tests not running to completion.
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 regards Aravinda On 01/07/2016 01:53 PM, Atin Mukherjee wrote: I have been always with this approach right from the beginning. We can definitely have nightly if not weekly NetBSD regressions to sanitize the changes, with that model we wouldn't need to eliminate BSD support but we can avoid this hard dependency in patch acceptance which has haunted us *multiple* times now. Thanks, Atin On 01/07/2016 12:38 PM, Joseph Fernandes wrote: +2 Avra - Original Message - From: "Avra Sengupta" To: "Gluster Devel" , "gluster-infra" Sent: Thursday, January 7, 2016 11:51:51 AM Subject: Re: [Gluster-infra] [Gluster-devel] NetBSD tests not running to completion. The same issue keeps coming up every few months, where all patch acceptances comes to a grinding halt with a dependency on NetBSD regressions. I have been re-trigerring my patches too, and they are not completing. Not to mention the long wait queue for them to run in the first place and then having them not complete. I know this issue has been discussed many times before and every time we have arrived at the conclusion that we need to have more stable tests, or a more robust infrastructure, but there's more to it than that. Here's listing down a few of the things I have observed: 1. Not many people are well versed with debugging the issues, that result in failure in NetBSD regression suites, simply because not many of us are familiar with the nuances of the platform. 2. If I am a developer interested in being a part of the gluster community and contributing code to it, the patches I send will have dependency on NetBSD regressions. When people who have been contributing for years now are finding it cumbersome to have the NetBSD regressions pass for their patches, imagine the impression and the impact on motivation it will have on a new developer. We need to ask ourselves how is this impacting a patch acceptance process. We can atleast try a different approaches to tackle this problem instead of just waiting for the test suite to stabilize or the infrastructure to get better. 1. We can have NetBSD as a separate port, and not have patches sent to the master branch be dependent on it's regression. 2. We can also have a nightly NetBSD regression run, instead of running it per patch. If a particular regression test fails, the owner of the test looks into it, and we debug the issue. One might say it's just delaying the problem, but atleast we will not have all patches acceptances blocked. 3. We really need to trigger regressions only on the patches that have been reviewed and have gotten a +2. This will substantially bring down the wait time. I remember Atin bringing this up a few months back, but it still hasn't been implemented. Can we please have this ASAP. Regards, Avra On 01/06/2016 05:49 PM, 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. Thanks, Ravi ___ Gluster-infra mailing list gluster-in...@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra ___ Gluster-infra mailing list gluster-in...@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-infra mailing list gluster-in...@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] NetBSD tests not running to completion.
I agree. Regards, Nithya - Original Message - > From: "Atin Mukherjee" > To: "Joseph Fernandes" , "Avra Sengupta" > > Cc: "Gluster Devel" , "gluster-infra" > > Sent: Thursday, January 7, 2016 1:53:47 PM > Subject: Re: [Gluster-devel] [Gluster-infra] NetBSD tests not running to > completion. > > I have been always with this approach right from the beginning. We can > definitely have nightly if not weekly NetBSD regressions to sanitize the > changes, with that model we wouldn't need to eliminate BSD support but > we can avoid this hard dependency in patch acceptance which has haunted > us *multiple* times now. > > Thanks, > Atin > > On 01/07/2016 12:38 PM, Joseph Fernandes wrote: > > +2 Avra > > > > - Original Message - > > From: "Avra Sengupta" > > To: "Gluster Devel" , "gluster-infra" > > > > Sent: Thursday, January 7, 2016 11:51:51 AM > > Subject: Re: [Gluster-infra] [Gluster-devel] NetBSD tests not running to > > completion. > > > > The same issue keeps coming up every few months, where all patch > > acceptances comes to a grinding halt with a dependency on NetBSD > > regressions. I have been re-trigerring my patches too, and they are not > > completing. Not to mention the long wait queue for them to run in the > > first place and then having them not complete. > > > > I know this issue has been discussed many times before and every time we > > have arrived at the conclusion that we need to have more stable tests, > > or a more robust infrastructure, but there's more to it than that. > > Here's listing down a few of the things I have observed: > > 1. Not many people are well versed with debugging the issues, that > > result in failure in NetBSD regression suites, simply because not many > > of us are familiar with the nuances of the platform. > > 2. If I am a developer interested in being a part of the gluster > > community and contributing code to it, the patches I send will have > > dependency on NetBSD regressions. When people who have been contributing > > for years now are finding it cumbersome to have the NetBSD regressions > > pass for their patches, imagine the impression and the impact on > > motivation it will have on a new developer. We need to ask ourselves how > > is this impacting a patch acceptance process. > > > > We can atleast try a different approaches to tackle this problem instead > > of just waiting for the test suite to stabilize or the infrastructure to > > get better. > > 1. We can have NetBSD as a separate port, and not have patches sent to > > the master branch be dependent on it's regression. > > 2. We can also have a nightly NetBSD regression run, instead of running > > it per patch. If a particular regression test fails, the owner of the > > test looks into it, and we debug the issue. One might say it's just > > delaying the problem, but atleast we will not have all patches > > acceptances blocked. > > 3. We really need to trigger regressions only on the patches that have > > been reviewed and have gotten a +2. This will substantially bring down > > the wait time. I remember Atin bringing this up a few months back, but > > it still hasn't been implemented. Can we please have this ASAP. > > > > Regards, > > Avra > > > > On 01/06/2016 05:49 PM, 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. > >> > >> Thanks, > >> Ravi > >> ___ > >> Gluster-infra mailing list > >> gluster-in...@gluster.org > >> http://www.gluster.org/mailman/listinfo/gluster-infra > > > > ___ > > Gluster-infra mailing list > > gluster-in...@gluster.org > > http://www.gluster.org/mailman/listinfo/gluster-infra > > ___ > > Gluster-devel mailing list > > Gluster-devel@gluster.org > > http://www.gluster.org/mailman/listinfo/gluster-devel > > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
