[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