Re: [webkit-dev] Volunteers to run commit-queue?
I rolled that patch out. Anders On Aug 12, 2009, at 12:51 PM, Oliver Hunt wrote: Looks to be due to r47110? --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Volunteers to run commit-queue?
There were a couple patches which contributed to today's redness. Thanks for the rollout! the commit-queue is back up and running. I'm still fixing bugs in it to make it more robust. -eric On Wed, Aug 12, 2009 at 3:04 PM, Anders Carlsson ander...@apple.com wrote: I rolled that patch out. Anders On Aug 12, 2009, at 12:51 PM, Oliver Hunt wrote: Looks to be due to r47110? --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Volunteers to run commit-queue?
The commit-queue is back up and running on my machine. I've fixed a few bugs along the way and will be posting more bug fix patches this afternoon. There is a lot of backlog from this weekend (which is good! it means people have been using the commit queue). It will be a while before the queue is back down to 0. Hopefully by end of day. -eric On Sat, Aug 8, 2009 at 10:32 AM, Adam Barth aba...@webkit.org wrote: Thanks Eric. You're in a good position to improve the tool in the process. :) Adam On Sat, Aug 8, 2009 at 10:28 AM, Eric Seidele...@webkit.org wrote: I'll take care of it. I have bugzilla-tool bugs to fix anyway. -eric On Sat, Aug 8, 2009 at 9:50 AM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, I'm going to be in Canada next week for USENIX Security, so I won't be able to run the commit-queue script. If you'd like to try your hand at running the script, I've attached it to this email. I need to re-write it in python so we can check it into the WebKitTools/Scripts directory. The commit-queue isn't polished yet, so you should be prepared to do a little hand holding with the script. The three main issues to be aware of are as follows: 1) The script takes over the working copy to apply patches, build, and test. I've been running it from a dedicated working copy so I can be productive while it runs. 2) The script is tries to be conservative in actually committing to the repository. That means if someone else commits to the same top-level directory during the build / test cycle, the script won't actually pull the commit trigger. It will just try to land the patch again in the next cycle. We might want to experiment with being slightly more aggressive here. 3) If a patch is bad (doesn't apply cleanly, doesn't build, doesn't pass all the tests), the script won't r- the patch automatically. It will just diligently try to land the patch each cycle. You should pay some attention when a patch fails and update the bug appropriately. One clear next step is to update the tool to set the commit-queue- flag when a patch fails. Other than that, you just need to watch the builtbots to make sure you didn't destroy the tree. :) Adam P.S., Protip: If you want to see which bugs are in the queue, you can run ./WebKitTools/Scripts/bugzilla-tool bugs-to-commit or use this (slightly less precise) Bugzilla query: https://bugs.webkit.org/buglist.cgi?query_format=advancedshort_desc_type=notregexpshort_desc= \[S60\]long_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0= flagtypes.name type0-0-0=equalsvalue0-0-0=commit-queue%2Bfield0-1-0=nooptype0-1-0=equalsvalue0-1-0= ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Volunteers to run commit-queue?
Hi webkit-dev, I'm going to be in Canada next week for USENIX Security, so I won't be able to run the commit-queue script. If you'd like to try your hand at running the script, I've attached it to this email. I need to re-write it in python so we can check it into the WebKitTools/Scripts directory. The commit-queue isn't polished yet, so you should be prepared to do a little hand holding with the script. The three main issues to be aware of are as follows: 1) The script takes over the working copy to apply patches, build, and test. I've been running it from a dedicated working copy so I can be productive while it runs. 2) The script is tries to be conservative in actually committing to the repository. That means if someone else commits to the same top-level directory during the build / test cycle, the script won't actually pull the commit trigger. It will just try to land the patch again in the next cycle. We might want to experiment with being slightly more aggressive here. 3) If a patch is bad (doesn't apply cleanly, doesn't build, doesn't pass all the tests), the script won't r- the patch automatically. It will just diligently try to land the patch each cycle. You should pay some attention when a patch fails and update the bug appropriately. One clear next step is to update the tool to set the commit-queue- flag when a patch fails. Other than that, you just need to watch the builtbots to make sure you didn't destroy the tree. :) Adam P.S., Protip: If you want to see which bugs are in the queue, you can run ./WebKitTools/Scripts/bugzilla-tool bugs-to-commit or use this (slightly less precise) Bugzilla query: https://bugs.webkit.org/buglist.cgi?query_format=advancedshort_desc_type=notregexpshort_desc=\[S60\]long_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=commit-queue%2Bfield0-1-0=nooptype0-1-0=equalsvalue0-1-0= commit-queue Description: Binary data ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Volunteers to run commit-queue?
I'll take care of it. I have bugzilla-tool bugs to fix anyway. -eric On Sat, Aug 8, 2009 at 9:50 AM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, I'm going to be in Canada next week for USENIX Security, so I won't be able to run the commit-queue script. If you'd like to try your hand at running the script, I've attached it to this email. I need to re-write it in python so we can check it into the WebKitTools/Scripts directory. The commit-queue isn't polished yet, so you should be prepared to do a little hand holding with the script. The three main issues to be aware of are as follows: 1) The script takes over the working copy to apply patches, build, and test. I've been running it from a dedicated working copy so I can be productive while it runs. 2) The script is tries to be conservative in actually committing to the repository. That means if someone else commits to the same top-level directory during the build / test cycle, the script won't actually pull the commit trigger. It will just try to land the patch again in the next cycle. We might want to experiment with being slightly more aggressive here. 3) If a patch is bad (doesn't apply cleanly, doesn't build, doesn't pass all the tests), the script won't r- the patch automatically. It will just diligently try to land the patch each cycle. You should pay some attention when a patch fails and update the bug appropriately. One clear next step is to update the tool to set the commit-queue- flag when a patch fails. Other than that, you just need to watch the builtbots to make sure you didn't destroy the tree. :) Adam P.S., Protip: If you want to see which bugs are in the queue, you can run ./WebKitTools/Scripts/bugzilla-tool bugs-to-commit or use this (slightly less precise) Bugzilla query: https://bugs.webkit.org/buglist.cgi?query_format=advancedshort_desc_type=notregexpshort_desc= \[S60\]long_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0= flagtypes.name type0-0-0=equalsvalue0-0-0=commit-queue%2Bfield0-1-0=nooptype0-1-0=equalsvalue0-1-0= ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Volunteers to run commit-queue?
Thanks Eric. You're in a good position to improve the tool in the process. :) Adam On Sat, Aug 8, 2009 at 10:28 AM, Eric Seidele...@webkit.org wrote: I'll take care of it. I have bugzilla-tool bugs to fix anyway. -eric On Sat, Aug 8, 2009 at 9:50 AM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, I'm going to be in Canada next week for USENIX Security, so I won't be able to run the commit-queue script. If you'd like to try your hand at running the script, I've attached it to this email. I need to re-write it in python so we can check it into the WebKitTools/Scripts directory. The commit-queue isn't polished yet, so you should be prepared to do a little hand holding with the script. The three main issues to be aware of are as follows: 1) The script takes over the working copy to apply patches, build, and test. I've been running it from a dedicated working copy so I can be productive while it runs. 2) The script is tries to be conservative in actually committing to the repository. That means if someone else commits to the same top-level directory during the build / test cycle, the script won't actually pull the commit trigger. It will just try to land the patch again in the next cycle. We might want to experiment with being slightly more aggressive here. 3) If a patch is bad (doesn't apply cleanly, doesn't build, doesn't pass all the tests), the script won't r- the patch automatically. It will just diligently try to land the patch each cycle. You should pay some attention when a patch fails and update the bug appropriately. One clear next step is to update the tool to set the commit-queue- flag when a patch fails. Other than that, you just need to watch the builtbots to make sure you didn't destroy the tree. :) Adam P.S., Protip: If you want to see which bugs are in the queue, you can run ./WebKitTools/Scripts/bugzilla-tool bugs-to-commit or use this (slightly less precise) Bugzilla query: https://bugs.webkit.org/buglist.cgi?query_format=advancedshort_desc_type=notregexpshort_desc=\[S60\]long_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=commit-queue%2Bfield0-1-0=nooptype0-1-0=equalsvalue0-1-0= ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
