Reviewboard - dependant branches
Can someone remind me of the process for proposing branches that depend on another branch that is still in review? I know it's been discussed here and on irc before, but I don't recall the specifics. I think that the steps are: 1. Just propose the branch in github, which will trigger the automatic reviewboard integration 2. run some rbt command line invocation to update reviewboard with the upstream branch name I just don't recall the exact invocation for #2 and I don't want to experiment and muck something up :) Cheers, -- John Weldon -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Reviewboard - dependant branches
On 18/12/14 03:01, John Weldon wrote: Can someone remind me of the process for proposing branches that depend on another branch that is still in review? I know it's been discussed here and on irc before, but I don't recall the specifics. I think that the steps are: 1. Just propose the branch in github, which will trigger the automatic reviewboard integration 2. run some rbt command line invocation to update reviewboard with the upstream branch name I just don't recall the exact invocation for #2 and I don't want to experiment and muck something up :) rbt post -u --parent name-of-parent-branch Cheers, -- John Weldon -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Blocking and unblocking merges
On Wed, Dec 17, 2014 at 4:26 PM, Menno Smits menno.sm...@canonical.com wrote: There seems to be some confusion as to how merges gets blocked and unblocked. Specifically: 1. How do merges get blocked? Juju-core bugs with the following criteria will block merges: a. status: 'Triaged', 'In Progress' or 'Fix Committed' b. importance: 'Critical' c. tags: 'regression' and 'ci' 2. Who/what decides to unblock merges? The Jenkins github-merge-juju job ( http://juju-ci.vapour.ws:8080/job/github-merge-juju) is configured to call the check_blockers.py script, maintained by the Juju-QA team. check_blockers.py queries Launchpad for bugs with the above criteria. master example: https://api.launchpad.net/devel/juju-core?ws.op=searchTasksstatus%3Alist=Triagedstatus%3Alist=In+Progressstatus%3Alist=Fix+Committedimportance%3Alist=Criticaltags%3Alist=regressiontags%3Alist=citags_combinator=All 1.20 example: https://api.launchpad.net/devel/juju-core/1.20?ws.op=searchTasksstatus%3Alist=Triagedstatus%3Alist=In+Progressstatus%3Alist=Fix+Committedimportance%3Alist=Criticaltags%3Alist=regressiontags%3Alist=citags_combinator=All Most often the Juju QA team will open these bugs and set the tags, when a test failure demonstrates a regression. If the pull request body includes fixes-BUG NUMBER, where BUG NUMBER is in the blocking list, the merge will go through. 3. How do merges get unblocked? Merges are unblocked when no bugs are returned with the above criteria. The bugs should be updated only after the committed fix has successfully passed the CI tests which discovered the regression. This will most often mean setting the status to 'Fix Released' when the solution involves code changes or removing the regression and/or CI tag, if the issue is discovered to be a test or CI issue. 4, If the unblock process involves manual steps, whose responsibility is it to perform those steps? The person or team that marked the bug as a regression is responsible for updating the bug, once they are satisfied with the fix. Most often this will be the Juju-QA team but if others discover a regression they too should have the power to block merges. Based on experience and observation, I think I know how at least some of this works but could we please have some authoritative answers? Thanks, Menno -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Blocking and unblocking merges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.12.2014 04:20, John George wrote: On Wed, Dec 17, 2014 at 4:26 PM, Menno Smits menno.sm...@canonical.com mailto:menno.sm...@canonical.com wrote: There seems to be some confusion as to how merges gets blocked and unblocked. Specifically: 1. How do merges get blocked? Juju-core bugs with the following criteria will block merges: a. status: 'Triaged', 'In Progress' or 'Fix Committed' b. importance: 'Critical' c. tags: 'regression' and 'ci' 2. Who/what decides to unblock merges? The Jenkins github-merge-juju job (http://juju-ci.vapour.ws:8080/job/github-merge-juju) is configured to call the check_blockers.py script, maintained by the Juju-QA team. check_blockers.py queries Launchpad for bugs with the above criteria. master example: https://api.launchpad.net/devel/juju-core?ws.op=searchTasksstatus%3Alist=Triagedstatus%3Alist=In+Progressstatus%3Alist=Fix+Committedimportance%3Alist=Criticaltags%3Alist=regressiontags%3Alist=citags_combinator=All 1.20 example: https://api.launchpad.net/devel/juju-core/1.20?ws.op=searchTasksstatus%3Alist=Triagedstatus%3Alist=In+Progressstatus%3Alist=Fix+Committedimportance%3Alist=Criticaltags%3Alist=regressiontags%3Alist=citags_combinator=All Most often the Juju QA team will open these bugs and set the tags, when a test failure demonstrates a regression. If the pull request body includes fixes-BUG NUMBER, where BUG NUMBER is in the blocking list, the merge will go through. 3. How do merges get unblocked? Merges are unblocked when no bugs are returned with the above criteria. The bugs should be updated only after the committed fix has successfully passed the CI tests which discovered the regression. This will most often mean setting the status to 'Fix Released' when the solution involves code changes or removing the regression and/or CI tag, if the issue is discovered to be a test or CI issue. 4, If the unblock process involves manual steps, whose responsibility is it to perform those steps? The person or team that marked the bug as a regression is responsible for updating the bug, once they are satisfied with the fix. Most often this will be the Juju-QA team but if others discover a regression they too should have the power to block merges. The problem often is nobody from QA is around to ask for help in certain times during the day. So there should be at least a person in each team knowing how (and having permissions as well, if needed) to re-run jobs that are stuck, mark the bug as Fix Released once the CI job passes after the fix lands. Another REALLY NEEDED feature is to re-queue PRs set for merging but bounced due to a CI block. This wastes days sometimes, or at the very least hours. Based on experience and observation, I think I know how at least some of this works but could we please have some authoritative answers? Thanks, Menno -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUkkBzAAoJENzxV2TbLzHwflIH+wQM8s8oV2i7b1PzsDzh9Zyu DhfkyIhxFQxTJGsV8RamcTDkjWeDhRZKB49UPzMdqNJr0XG/KvVy1SyqICxJ5qoz uWnnrdumzUhF0k/hjsUEnOpNDBOnubUIoGHBVyyx6UEMRgW+G0pFTIhUQGqEPhhU 7YMqn/r3GpiSnkmnknB/U4yk9TEYViDBRuPzSmhJiSwBGqkpOW+ISkWstUgbqYO+ o9KzxREWcvEDQ0+v0RLpaF2HsUWwktn7HL2BuoemhU4hoS5/ohD0VR5AemXwUyky ISEiqu4atjPcCxJts5UpPhhznBSVHFlOm4ROkH1ku+x671WZEZZXoUt4CjWbxvo= =l5mJ -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Blocking and unblocking merges
... 3. How do merges get unblocked? Merges are unblocked when no bugs are returned with the above criteria. The bugs should be updated only after the committed fix has successfully passed the CI tests which discovered the regression. This will most often mean setting the status to 'Fix Released' when the solution involves code changes or removing the regression and/or CI tag, if the issue is discovered to be a test or CI issue. Note that being just a test issue doesn't entirely excuse it, because it means that the test suite will just fail again, and we won't have visibility into real problems. (We get into a mode where we expect the test suite to fail, and stop trusting it.) 4, If the unblock process involves manual steps, whose responsibility is it to perform those steps? The person or team that marked the bug as a regression is responsible for updating the bug, once they are satisfied with the fix. Most often this will be the Juju-QA team but if others discover a regression they too should have the power to block merges. The problem often is nobody from QA is around to ask for help in certain times during the day. So there should be at least a person in each team knowing how (and having permissions as well, if needed) to re-run jobs that are stuck, mark the bug as Fix Released once the CI job passes after the fix lands. Another REALLY NEEDED feature is to re-queue PRs set for merging but bounced due to a CI block. This wastes days sometimes, or at the very least hours. One thing Tim mentioned was whether we could have the bot comment I'm not merging this now because of a CI failure, but leave the request in the Queue, so it is automatically retried when the branch is unblocked. I'm not sure if there is an efficiency/event problem (we got an event that the $MERGE$ message was set, we wouldn't get another one unless someone pokes the branch.) But it does seem possible. John =:- Based on experience and observation, I think I know how at least some of this works but could we please have some authoritative answers? Thanks, Menno -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUkkBzAAoJENzxV2TbLzHwflIH+wQM8s8oV2i7b1PzsDzh9Zyu DhfkyIhxFQxTJGsV8RamcTDkjWeDhRZKB49UPzMdqNJr0XG/KvVy1SyqICxJ5qoz uWnnrdumzUhF0k/hjsUEnOpNDBOnubUIoGHBVyyx6UEMRgW+G0pFTIhUQGqEPhhU 7YMqn/r3GpiSnkmnknB/U4yk9TEYViDBRuPzSmhJiSwBGqkpOW+ISkWstUgbqYO+ o9KzxREWcvEDQ0+v0RLpaF2HsUWwktn7HL2BuoemhU4hoS5/ohD0VR5AemXwUyky ISEiqu4atjPcCxJts5UpPhhznBSVHFlOm4ROkH1ku+x671WZEZZXoUt4CjWbxvo= =l5mJ -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
