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 <[email protected]> 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 <[email protected]> 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<[email protected]> 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 <[email protected]> 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=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= >> >> >> >> _______________________________________________ >> >> webkit-dev mailing list >> >> [email protected] >> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >> > >> > >> > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
