Re: [openstack-dev] additional core review criteria - recent Jenkins pass - otherwise you break the gates
On Fri, Dec 20, 2013 at 12:09 PM, Julien Danjou jul...@danjou.info wrote: On Thu, Dec 19 2013, Sean Dague wrote: So please look for recent passes before +Aing anything. What about making that automatic? Same question for patchset that stays that for a month, finally got approved and fails right away because they cannot be merged. It would be cool to notify the submitter as soon as the patch is detected non-mergeable. I was talking to clarkb on IRC about this earlier, and the next release of gerrit should be able to run cron jobs which test for mergability. So, we're getting there. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] additional core review criteria - recent Jenkins pass - otherwise you break the gates
On Thu, Dec 19 2013, Sean Dague wrote: So please look for recent passes before +Aing anything. What about making that automatic? Same question for patchset that stays that for a month, finally got approved and fails right away because they cannot be merged. It would be cool to notify the submitter as soon as the patch is detected non-mergeable. -- Julien Danjou -- Free Software hacker - independent consultant -- http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] additional core review criteria - recent Jenkins pass - otherwise you break the gates
Jim and I have been talking about both of these ideas for months. We aren't lacking clever solutions to make this better. However they are lacking implementors. Volunteers welcomed. Until such time, this is completely solvable problem by people taking and extra 5 seconds before approving a patch to merge. I expect a core reviewer to look back through the history of comments to make sure they aren't ignoring other people's feedback. It doesn't seem unreasonable that people that core reviewers also understand that there is a lot of responsibility with that power, and what the impact on others is if you +A things into the gate. John Griffith john.griff...@solidfire.com wrote: On Thu, Dec 19, 2013 at 5:41 PM, Sean Dague s...@dague.net wrote: https://review.openstack.org/#/c/51793/ Just curious, what about the possibility of automating this? In other words, run through idle patches any time the gate volume gets below a certain threshold. If you come across a patch that hasn't been visited/modified in over say a week, and it doesn't have any failures (-1's, -2's etc) then go ahead an run a check on it. The volume will likely prevent it from keeping all of them updated but it might make a significant dent. Might work, might not. But if the simple action described above causes *hours* of gate delay it very well may be more than worth making an attempt to automate IMO. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
