[Gluster-devel] good job on fixing heavy hitters in spurious regressions

Pranith Kumar Karampuri pkarampu at redhat.com
Fri May 8 18:31:38 UTC 2015


> I agree on the experience and have no questions/comments on that.
>
> The deal is though, we at least had people (including myself) ignoring 
> spurious failures, re-triggering jobs, to get that +1 V and move on. 
> Which causes issues, as the failures could have been at least flagged 
> for others to be aware of and take forward. Which is the reason the 
> patch submitter is the first to take a stab at correcting the problem.
>
> We can always mail the owner next and then move on to the maintainer 
> (which is what you did).
>
> I would say we stop any merge if its history shows no analysis of 
> regression failures (assuming regression failures occurred). This is a 
> maintainer role that does this. (changing tracks: Let's please be more 
> vocal in Gerrit, we can mark issues addressed as "Done" and also write 
> a few lines on what is going on in terms of tests done etc.)
>
> On people moving on and having no time for older areas/code, I guess 
> we have to be stronger maintainers, as they are the only ones left to 
> deal with the problem then. In which case, we should deal with this 
> earlier than later, mandating _quality_ test cases for changes, than 
> accepting things on the face of the code. Of course this is not 
> correctable in retrospection now, so something for the future.
+1

Pranith


More information about the Gluster-devel mailing list