On 17 Apr 2015, at 16:02, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote: > As mentioned in a previous email, recent changes to speed up regression > testing have uncovered a problem with how we track the verified status > of patches. Specifically, the fault sequence is as follows: > > 1) Regression fails, "Gluster Build System" adds V-1 > > 2) NetBSD regression passes, "NetBSD Build System" adds V+1 > > 3) Smoke passes, "Gluster Build System" erases the V-1 > > The order of the first two might be reversed. What's new is that > regression never used to finish before smoke, and now it usually does > (for the failure case). So, reviewers/committers, please be sure to > check the last *regression* result before assuming that green check mark > is valid. I'm periodically going through the list of recently reviewed > patches and manually fixing up the status, but I can't catch all of them > and TBH don't know how much longer I'll keep trying. > > Gerrit/Jenkins maintainers: we have three options for a long term > solution. > > a) Run smoke and regression as separate Gerrit users, require > concurrence for a patch to be considered V+1. This is what we > already do for NetBSD. It's simple, and seems to work well. > > b) Stop triggering regression directly from the Gerrit event, trigger it > from a successful smoke completion instead. This is a bit more > complicated, but has the additional benefit that regression *won't > even run* if smoke fails (saving resources). > > c) Write a script to seek out and destroy improperly marked patches > (basically automate what I've been doing the last coupld of days). > It'll work, but it still leaves a window when patches are improperly > marked. We should only consider it if we run into significant > problems with the other two approaches. > > Anyone else have any preference for (a) vs. (b)? I can't implement (a) > myself. I could implement (b), but I don't want to go messing with the > Jenkins configuration unless/until we have a consensus that it's the > right thing to do. (a) sounds good to me. Vijay can setup the Gerrit account if he's agreeable. :) I'm focused on other Gerrit issues atm. :( + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
