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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
