> 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.
On the other hand, if patch A starts blocking all merges because of
NetBSD
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:15 PM, Jeff Darcy wrote:
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.
On the other hand, if patch A starts blocking all merges because of
NetBSD failures, then all platforms - including
On Thu, Jan 07, 2016 at 03:01:41PM +0530, Avra Sengupta wrote:
> Why is this a bad idea?
Because each week you will have multiple regressins introduced. Few
people will be willing to investigate wether they pushed a patch that
caused a regression, and that few people will have to deal the others
Le lundi 04 janvier 2016 à 17:27 +0100, Michael Scherer a écrit :
> - salt in epel is still using a old version ( for dependencies reasons
> ). While this is working well enough, it make contributing quite
> difficult, and prevent using some new features that are needed.
of course, the fun is
- 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
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