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=advanced&short_desc_type=notregexp&short_desc=\[S60\]&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=commit-queue%2B&field0-1-0=noop&type0-1-0=equals&value0-1-0=
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 <abarth@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=advanced&short_desc_type=no... \[S60\]&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0= flagtypes.name &type0-0-0=equals&value0-0-0=commit-queue%2B&field0-1-0=noop&type0-1-0=equals&value0-1-0=
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
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 Seidel<eric@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 <abarth@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:
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
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 <abarth@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 Seidel<eric@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 <abarth@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=advanced&short_desc_type=no... \[S60\]&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0= flagtypes.name &type0-0-0=equals&value0-0-0=commit-queue%2B&field0-1-0=noop&type0-1-0=equals&value0-1-0=
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
The tree is just too red today for the commit queue to work. :( Waiting for things to green up before I try again. -eric On Tue, Aug 11, 2009 at 12:20 PM, Eric Seidel <eric@webkit.org> wrote:
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 <abarth@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 Seidel<eric@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 <abarth@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=advanced&short_desc_type=no... \[S60\]&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0= flagtypes.name &type0-0-0=equals&value0-0-0=commit-queue%2B&field0-1-0=noop&type0-1-0=equals&value0-1-0=
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
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
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 <andersca@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
participants (4)
-
Adam Barth
-
Anders Carlsson
-
Eric Seidel
-
Oliver Hunt