On Fri, Jul 7, 2017 at 9:51 AM, Atin Mukherjee <amukherj@xxxxxxxxxx> wrote:
Not sure if it is feasible. All we can do is, if its confirmed that a given patch is caused the issue, we should revert it (manually or automatically), and let the author/maintainer now about the revert. I guess it should be part of the work-flow so we don't have to bother about figuring out whose responsibility it is.
This makes me think as a maintainer we do need to ensure the if the regression vote on the patch is quite old, a rebase of the patch is must to be on the safer side?Krutika,tests/basis/stats-dump.t is failing all the time and as per my initial analysis after https://review.gluster.org/#/c/17709/ got into the mainline the failures are seen and reverting this patch makes the test to run successfully. I do understand that the centos vote for this patch was green but the last run was on 5th June which was 1 month back. So some other changes have gone into in between which is now causing this patch to break the test.
Not sure if it is feasible. All we can do is, if its confirmed that a given patch is caused the issue, we should revert it (manually or automatically), and let the author/maintainer now about the revert. I guess it should be part of the work-flow so we don't have to bother about figuring out whose responsibility it is.
Open to hear more suggestions here.
-Amar
~Atin
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--
Amar Tumballi (amarts)
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
