Re: [webkit-dev] Python on the Tiger build bot
On May 10, 2010, at 11:01 PM, Eric Seidel wrote: On Mon, May 10, 2010 at 2:25 AM, Maciej Stachowiak m...@apple.com wrote: My feeling about requiring a higher Python version for Tiger remains this: I'd prefer that we provide an easy means to do the install of Python 2.6 (ideally a single script you can run, and ideally without affecting the system copy), rather than making every Tiger developer figure it out on their own. http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html For those of us who still need to support Tiger, it would be a huge hassle to have to figure out how to update Python manually to even run the layout tests. The fact that it's not a primary development platform doesn't mean that it's ok to add stumbling blocks to the development process. In fact, it kinda makes it less ok, because then it takes more work to shift gears when fixing a Tiger-specific bug. Provided: https://bugs.webkit.org/show_bug.cgi?id=38886 At minimum, there should be instructions here, and ideally the install should be one step: http://webkit.org/building/tools.html Provided: https://bugs.webkit.org/show_bug.cgi?id=38822 Yay thanks! (Will try to review these later if no one beats me.) Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] prepare-Changelog crashing on cygwin
More information about rebase here: http://www.tishler.net/jason/software/rebase/rebase-2.2.README I still haven't found any way to detect the problem so we could warn people before scripts start blowing up. -eric On Mon, May 10, 2010 at 1:33 PM, Peter Kasting pkast...@google.com wrote: On Mon, May 10, 2010 at 1:27 PM, Tony Gentilcore to...@chromium.org wrote: On Mon, May 10, 2010 at 1:07 PM, Eric Seidel e...@webkit.org wrote: Is this caused by the base load address of both perl and svn conflicting/overlapping? (I don't really know how CYGWIN works.) I'm by no means a cygwin expert. I just happened to run into the same problem last week. This thread is where I found that solution (first suggested by evan): http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/bac1846c2678152d/4b9548cdd7214e4e Note that the official webkit.org instructions tell you to do this: http://webkit.org/building/tools.html Is this something we should detect in our scripts and warn about? I believe it's possible by checking the existing base addresses of the modules. I'm not sure on exactly how to do it. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit Nightly website scripts
Those which can be found in SVN can be found here: http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/ Last I heard, the rest are on Mark Rowe's harddrive, somewhere. -eric On Sat, May 8, 2010 at 5:10 PM, Trevor Downs cybersk...@mac.com wrote: Hi. I'm trying to find the scripts for http://nightly.webkit.org, but I can't find them in the SVN. Would someone be kind enough to direct me to them? Sincerely, Trevor Downs, un-certified looney ___ 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] Yet another bug-less change hosed the tree.
On Mon, May 10, 2010 at 11:39 PM, Eric Seidel esei...@google.com wrote: On Mon, May 10, 2010 at 2:30 PM, Geoffrey Garen gga...@apple.com wrote: 2) Your patch can be vetted by the various bots that analyze patches posted for review. True, if what you're really asking for is not just a bug report but also a cooling off period during which you wait for a result from the EWS bot, even if you get a review right away. You get greater value in the case of a bad patch, but also greater cost in the case of every patch. I'm not a big fan of the current delay. We need to make the EWS cycletime shorter. That said, I commonly see the Qt bot and Style bots cycle before I even get a chance to go pull up my bug URL to send it to someone. The bots themselves are generally very quick (except windows), but they only poll every 5 minutes, which makes them feel slow. We just need to spend the engineering effort to make this faster. Instead of having all the bots poll Bugzilla every 5 minutes, we can reduce the load and make everything faster by having only one bot poll and then push the info to the other bots via some other channel (XMPP? IRC?). That's probably an days worth of work. If that's not fast enough, we can have webkit-patch upload ping a server to kick off the push events. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
On Mon, May 10, 2010 at 6:04 PM, Brent Fulgham bfulg...@gmail.com wrote: On Mon, May 10, 2010 at 2:44 PM, Adam Barth aba...@webkit.org wrote: On Mon, May 10, 2010 at 2:30 PM, Geoffrey Garen gga...@apple.com wrote: 2) Your patch can be vetted by the various bots that analyze patches posted for review. True, if what you're really asking for is not just a bug report but also a cooling off period during which you wait for a result from the EWS bot, even if you get a review right away. You get greater value in the case of a bad patch, but also greater cost in the case of every patch. Yes, this way of doing things has more overhead for you personally but saves overhead for everyone else in the project. The question, as I see it, is which of these quantities is larger. The more people that work on the project, the bigger the multiplier on the right. I'm not sure this is totally correct. I'm sure more people than ggaren find the TPS cover sheet / cooling off period to be an added cost. These added costs apply to *all* developers, whether they land bad patches or not. I would like to debunk the cooling off period myth. There is no one telling you (besides your reviewer) that you need to wait for all the EWS bots to cycle. They're there for informational (Warning, it's in their name even) purposes only. If your reviewer is happy to r+ before the bots have cycled, go for it. :) You seem to be advocating a system that imposes a (perhaps small) cost on every development 'transaction' as insurance against the (possibly high) cost of a build breakage. I'm not sure the cost/benefit is clear here. As Maciej states, webkit-patch upload is pretty quick (at least for git users). Quicker to me, than trying to send an email, or get paste-bin review. The other advantage for me (personally) of using bugzilla for all my reviews is that I can mark them commit-queue=? and then chuck them from my tree. I understand that that doesn't necessarily work for everyone as well, especially with the tree being red enough as of late that the cq has been blocked for sometimes days at a time. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
Sent from the wrong email address the first time, sorry. 2) Your patch can be vetted by the various bots that analyze patches posted for review. True, if what you're really asking for is not just a bug report but also a cooling off period during which you wait for a result from the EWS bot, even if you get a review right away. You get greater value in the case of a bad patch, but also greater cost in the case of every patch. I'm not a big fan of the current delay. We need to make the EWS cycletime shorter. That said, I commonly see the Qt bot and Style bots cycle before I even get a chance to go pull up my bug URL to send it to someone. The bots themselves are generally very quick (except windows), but they only poll every 5 minutes, which makes them feel slow. In either case, there is no minimum cooling off period. You can always chose to ignore the bots. But not posting to a patch means you asked someone to do a review without critical data like does it build. :) Personally I reject any patches which aren't submitted to me via bugzilla, the bots take care of so much of the reviewing for me. :) 3) The but serves as a coordination point for dealing with bustage caused by a patch and for regressions detected later. Isn't it just as easy to open a bug on demand, if regressions are detected? Opening bugs after the fact is possible. The sherriffbot knows how to do that, iirc. But it's much easier if the commit itself has the bug number so that no one has to go searching for a bug number after the fact. :) Personally, I'd prefer it if we kept the TPS reports in our project to a minimum. In this case, a TPS report would have been more typing than the patch itself. That's part of what motivated us to create webkit-patch, which makes creating and managing bugs and patches quite easy. Less TPS is entirely the reason for webkit-patch. :) At least my reasons. Maybe I would use webkit-patch if it really were quite easy. I tried it in earnest for a while, but I had to give it up because: * I couldn't find a ChangeLog workflow that fit its demands, so using it was actually more complicated than doing everything by hand - I would be interested to know more. * It didn't handle subdirectory-only work - Yes, not being an SVN user I don't feel this pain, but I agree this needs fixing. https://bugs.webkit.org/show_bug.cgi?id=28445 is one related bug. * It often failed with mysterious error messages - Would love to know more. :) When you go cowboy and commit without building and testing, you impose costs on everyone else in the project. Probably not fair to conflate shooting a six-shooter with committing without filling out a bugzilla form first. Well, in the 3 commits in question all of them broke Snow Leopard, which means that either whoever wrote them isn't using a Mac, or they just didn't build themselves. Including a bug number has numerous benefits, but it certainly isn't a panacea and certainly doesn't solve the general shoot-from-the-hip-and-run-away behavior. :) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
On May 10, 2010, at 11:45 PM, Eric Seidel wrote: As Maciej states, webkit-patch upload is pretty quick (at least for git users). I'm not a git user but I still find it more convenient than any other approach because it has fewer steps and it helps me avoid some common mistakes. I do think making it capable of handling subdirectories would be an improvement for SVN users. Also, I suspect it doesn't work as well as it could for people who prefer to edit ChangeLogs in a non-command- line editor, and for people who are very much in the habit of running prepare-ChangeLog before they even think about uploading a patch. Even with those limitations, I personally find it very useful, and I am a grumpy curmudgeon about tools. On a tangential note, I think another thing that would help in these particular cases is enabling more of our JS-only tests to run as part of run-javascriptcore-tests, so it's easier for JS hackers to run them without having to wait on a WebCore world rebuild. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
11.05.2010, в 0:56, Maciej Stachowiak написал(а): I do think making it capable of handling subdirectories would be an improvement for SVN users. Also, I suspect it doesn't work as well as it could for people who prefer to edit ChangeLogs in a non- command-line editor, and for people who are very much in the habit of running prepare-ChangeLog before they even think about uploading a patch. Even with those limitations, I personally find it very useful, and I am a grumpy curmudgeon about tools. FWIW, I'm unwilling to use a command line tool to deal with Bugzilla, no matter how refined. I don't work on a browser engine to run away from the experience it provides. It would be interesting to know if I'm alone in feeling this way. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
On Tue, May 11, 2010 at 5:51 PM, Alexey Proskuryakov a...@webkit.org wrote: 11.05.2010, в 0:56, Maciej Stachowiak написал(а): I do think making it capable of handling subdirectories would be an improvement for SVN users. Also, I suspect it doesn't work as well as it could for people who prefer to edit ChangeLogs in a non-command-line editor, and for people who are very much in the habit of running prepare-ChangeLog before they even think about uploading a patch. Even with those limitations, I personally find it very useful, and I am a grumpy curmudgeon about tools. FWIW, I'm unwilling to use a command line tool to deal with Bugzilla, no matter how refined. I don't work on a browser engine to run away from the experience it provides. The problem with the experience is not the web browser but bugzilla + integration with other tools. Maybe if you were editing in bespin and using some sort of cloud based compiling farm (cool idea...) then it'd make sense to stay in the browser for the patch review/tracking side of things. But the reality is that most of us use some sort of IDE/editor + command line tools to do our job. I don't see how not using a web browser for one particular task on one particular site (that's not very great anyway) is somehow betraying the product you're working on. J P.S. Thanks so much everyone who's worked on webkit-patch! It takes SO much pain out of working on WebKit. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit-patch vs manual steps [was Re: Yet another bug-less change hosed the tree.]
- On Tue, May 11, 2010 at 9:51 AM, Alexey Proskuryakov a...@webkit.org wrote: 11.05.2010, в 0:56, Maciej Stachowiak написал(а): I do think making it capable of handling subdirectories would be an improvement for SVN users. Also, I suspect it doesn't work as well as it could for people who prefer to edit ChangeLogs in a non-command-line editor, and for people who are very much in the habit of running prepare-ChangeLog before they even think about uploading a patch. Even with those limitations, I personally find it very useful, and I am a grumpy curmudgeon about tools. FWIW, I'm unwilling to use a command line tool to deal with Bugzilla, no matter how refined. I don't work on a browser engine to run away from the experience it provides. It would be interesting to know if I'm alone in feeling this way. I'm not sure why it matters, but I'll participate anyway :) I like being able to do either. By Hand - Quite often, I do things by hand because I feel more in control of the process and what gets put up. - Also, I like the stability of my revision control system and prepare-ChangeLog (neither of which is changed very often or much) -- unlike webkit-patch which changes frequently. ( I'm jaded due to my experiences in chromium where the infrastructure tools must be used and also have needed debugging them before I could use them more than once.) command line tool - I've found it handy at times. (At the same time, submitting the patch itself is usually the least amount of work -- currently, it feels like getting a good object model proposal is the hardest part :) ). - WBR, Alexey Proskuryakov ___ 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] Clearing a textfield's 'autofilled' status on change, not focus
HTMLInputElement's 'autofilled' property is cleared when the field gets focused[1]. This has the visible effect of clearing the pale- yellow background color to white. Safari only seems to use this background-color highlighting for autofill of names, emails, addresses, etc., but Chrome also uses it for autofilled usernames and passwords in login forms. In login forms at least, the current UI seems wrong[2]. That's partly because the form is often filled in automatically when the page is loaded (so a script that focuses a field on page load can end up clearing the highlight); and partly because the password is unreadable, so it's impossible to tell from inspection whether it's still autofilled or edited by the user. Are there strong feelings in favor of the current UI, or would it be OK to change it overall so that the autofilled property is only cleared when the text is user-modified? If the current UI needs to stay the same, could we compromise by changing the behavior of the property in login forms only, since such a change would have no visible effect in Safari? —Jens [1] See HTMLInputElement::handleFocusEvent, currently line 753. [2] http://code.google.com/p/chromium/issues/detail?id=38386 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
On May 11, 2010, at 9:51 AM, Alexey Proskuryakov wrote: 11.05.2010, в 0:56, Maciej Stachowiak написал(а): I do think making it capable of handling subdirectories would be an improvement for SVN users. Also, I suspect it doesn't work as well as it could for people who prefer to edit ChangeLogs in a non- command-line editor, and for people who are very much in the habit of running prepare-ChangeLog before they even think about uploading a patch. Even with those limitations, I personally find it very useful, and I am a grumpy curmudgeon about tools. FWIW, I'm unwilling to use a command line tool to deal with Bugzilla, no matter how refined. I don't work on a browser engine to run away from the experience it provides. It would be interesting to know if I'm alone in feeling this way. I like the command-line tool as a way to upload patches for two basic reasons: 1) The bugzilla Web-based process for filing a bug and uploading a patch sucks. Too many steps and too many fields to fill in. We could definitely streamline this if we cared to. 2) It requires a command-line tool to create a patch in the first place. Thus, no matter how much we streamline the Web experience for uploading a patch, using it will result in an extra step. I don't foresee the Web interface being able to create a patch in the foreseeable future. I do use the bugzilla Web interface for commenting on bugs, reading patches, reviewing patches, etc. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Behavior of file:// URLs when dragging
On Mon, May 10, 2010 at 5:48 PM, Daniel Cheng dch...@chromium.org wrote: From the discussion on https://bugs.webkit.org/show_bug.cgi?id=25882, I believe the general consensus is that file:// URLs should not be exposed when dragging and dropping. Removing file:// URL population from event.dataTransfer is pretty easy; however, what should we do when the user drops a file in an editable area? Right now, it creates a link with the file URL, which (I think) defeats the point of removing file:// URLs from event.dataTransfer. I think the right behavior here is to return DragOperationNone unless the active target element is a file input or it's a non-editable element that handles files in event.dataTransfer, but I'd like to see what other people think first. I think there was a suggestion in that bug to only drop the filename into the editable area, without the full path. I'm not sure if it is better then DragOperationNone though. On a tangent, I noticed that a lot of implementations of DragData::asURL try to check that a file URL points at a file that actually exists. What is the rationale for doing the file existence check in DragData? The loader has to check for existence anyway, so why not just let the loader do it? This should save some IO time, especially if the file is on a slow NFS share in another continent. Does anyone depend on asURL's undocumented behavior to not return file URLs that point to non-existent files? (If so, I'd be willing to argue that they shouldn't be doing that anyway.) If not, I'd like to remove that behavior. Daniel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
For fun, I scrolled back through WebCore/ChangeLog looking for a non-build fix that was missing a bug link. The first one I found was 160 revs ago. I suspect the vast majority of patches already have bug reports. Did you verify that they all waited for EWS bot results before committing? We require a ChangeLog for every patch. Isn't that a TPS report? No. A ChangeLog is much less time-consuming to manage. Another perspective is that we have lots of tools to help you not break the build. If you bypass those tools and break the build, you're going to piss people off. We've discussed having a rigid green tree policy in the past. This line of discussion seems to say, We know the project decided against a rigid green tree policy, but we'd like to have one anyway. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
True, if what you're really asking for is not just a bug report but also a cooling off period during which you wait for a result from the EWS bot, even if you get a review right away. You get greater value in the case of a bad patch, but also greater cost in the case of every patch. Yes, this way of doing things has more overhead for you personally but saves overhead for everyone else in the project. The question, as I see it, is which of these quantities is larger. The more people that work on the project, the bigger the multiplier on the right. I don't think it's fair to frame my perspective as me personally and your perspective as everyone else in the project. It's interesting that I caught just as much flak from Eric today for turning the buildbot red, even though the bot was red for only a short time, the bot was only red because of a 32-bit / 64-bit difference that didn't show up in my 32-bit testing, and my patch had a bugzilla bug. My guess is that the real complaint here is that the bot was red at all. If you'll permit me to editorialize, my guess is that some Google employees prefer a rigid green tree policy because it matches their internal development process, and it makes integrating with that process and committing patches for other Google employees easier. The rigid green tree policy you seek would make some things easier. It would also impose costs on everyone in the project. It is definitely not obvious that everyone on the project shares your preference. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
On Tue, May 11, 2010 at 2:20 PM, Geoffrey Garen gga...@apple.com wrote: Yes, this way of doing things has more overhead for you personally but saves overhead for everyone else in the project. I don't think it's fair to frame my perspective as me personally and your perspective as everyone else in the project. I don't think that's a valid interpretation of the above sentence. It seems to simply be saying there is a cost to the patch creator of running the patch past the bots, and there is a cost to the developer community at large if the tree is broken, which is undeniably true. If you'll permit me to editorialize, my guess is that some Google employees prefer a rigid green tree policy because it matches their internal development process, and it makes integrating with that process and committing patches for other Google employees easier. As a Google employee I am puzzled as to how a green tree policy makes integrating with the process and committing patches for other Google employees easier. You seem to be suggesting that familiarity/similarity to another policy is some sort of benefit. I can't see how that's true, nor have I ever heard a Google employee suggest such. For the people who would prefer a green tree policy, I suspect the rationale is that they believe it lowers overall development costs, irrespective of what other policies on other projects may be, which clearly you do not agree with. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
Maybe I would use webkit-patch if it really were quite easy. I tried it in earnest for a while, but I had to give it up because: * I couldn't find a ChangeLog workflow that fit its demands, so using it was actually more complicated than doing everything by hand Can you explain this in more detail? I don't know how to do either of these steps in an easy way: 1. Once I have a patch with a ChangeLog, say, File a new bug and upload this patch for review. (Bonus points if the tool automatically made the first line of the ChangeLog the title of the bug.) 2. Once the patch has been reviewed, say, Add bug # and reviewer information from Bugzilla, commit, and close the bug. (Bonus points if the commit happens via the bugzilla patch, so I can move on to working on another patch.) I'd be willing to try any set of steps that accomplishes these tasks. The last time I tried it, webkit-patch was close, but it never quite got there. The ChangeLog seemed to be the main sticking point. I've optimized the tool for my workflow because that's the workflow I understand. I'm happy to optimize it for other workflows too. * It didn't handle subdirectory-only work I think here you're refer to the fact that SVN is slow. There was a thread earlier about making webkit-patch operate on the current directory instead of on whole working copy. We can certainly do that if you'd find that helpful. Yes, I'd find it helpful. Slow is one problem. But I also tend to have patches in different parts of the tree -- for example, WebKitTools -- which I don't want to include in my uploaded patch. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
On May 11, 2010, at 2:30 PM, Geoffrey Garen wrote: Maybe I would use webkit-patch if it really were quite easy. I tried it in earnest for a while, but I had to give it up because: * I couldn't find a ChangeLog workflow that fit its demands, so using it was actually more complicated than doing everything by hand Can you explain this in more detail? I don't know how to do either of these steps in an easy way: 1. Once I have a patch with a ChangeLog, say, File a new bug and upload this patch for review. (Bonus points if the tool automatically made the first line of the ChangeLog the title of the bug.) In the case where you don't have a ChangeLog, you can use webkit- patch upload to do all these things. But I believe the step where it lets you edit the ChangeLog may not work great if you use a non- command-line text editor. I think if you set the EDITOR enviornment variable to open -t -W, it may do what you want - the ChangeLog will be opened in Xcode and the webkit-patch script will wait until you quit. It also doesn't modify an existing ChangeLog entry if you already made one. 2. Once the patch has been reviewed, say, Add bug # and reviewer information from Bugzilla, commit, and close the bug. (Bonus points if the commit happens via the bugzilla patch, so I can move on to working on another patch.) This one is easy: A) webkit-patch land (if the patch is already in your tree) B) webkit-patch land-from-bug BUGID (to pull it from bugzilla) It will fill in the reviewer in the ChangeLog, commit the patch, and mark the bugzilla bug closed. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Yet another bug-less change hosed the tree.
On Tue, May 11, 2010 at 2:11 PM, Geoffrey Garen gga...@apple.com wrote: For fun, I scrolled back through WebCore/ChangeLog looking for a non-build fix that was missing a bug link. The first one I found was 160 revs ago. I suspect the vast majority of patches already have bug reports. Did you verify that they all waited for EWS bot results before committing? Nope, although I suspect that most patches are up for review for more than a few minutes. :) We require a ChangeLog for every patch. Isn't that a TPS report? No. A ChangeLog is much less time-consuming to manage. I think a good goal is for bug management to take less time than dealing with ChangeLogs. Another perspective is that we have lots of tools to help you not break the build. If you bypass those tools and break the build, you're going to piss people off. We've discussed having a rigid green tree policy in the past. This line of discussion seems to say, We know the project decided against a rigid green tree policy, but we'd like to have one anyway. You're saying that breaking the tree doesn't piss people off? As a random example, I've had dhyatt yell at me in IRC when I've broken the tree. In fact, before we had these tools, I used to break the tree a lot and got yelled at by plenty of folks, including Mark Rowe. On Tue, May 11, 2010 at 2:30 PM, Geoffrey Garen gga...@apple.com wrote: Maybe I would use webkit-patch if it really were quite easy. I tried it in earnest for a while, but I had to give it up because: * I couldn't find a ChangeLog workflow that fit its demands, so using it was actually more complicated than doing everything by hand Can you explain this in more detail? I don't know how to do either of these steps in an easy way: 1. Once I have a patch with a ChangeLog, say, File a new bug and upload this patch for review. (Bonus points if the tool automatically made the first line of the ChangeLog the title of the bug.) Yeah, we don't handle that case very well. I've filed https://bugs.webkit.org/show_bug.cgi?id=38945. We need some code to fill the bug URL into an existing ChangeLog that similar to the code we use to fill in the reviewer. 2. Once the patch has been reviewed, say, Add bug # and reviewer information from Bugzilla, commit, and close the bug. (Bonus points if the commit happens via the bugzilla patch, so I can move on to working on another patch.) There are two cases here: A) Your working copy has a ChangeLog that references the bug but says Reviewed by NOBODY. B) Your working copy has a ChangeLog that does not reference a bug, but the patch was already reviewed in bugs.webkit.org. In case (A), all you need to do is type webkit-patch land as Maciej mentioned in a later email. (Note, you might have to update to top-of-tree if your checkout is out of date, like you need to with svn commit.) If you mean case (B), you shouldn't get into that case once we fix (1) above because we'll fill in the bug number into the ChangeLog when you upload it to bugs.webkit.org (which happens before the patch can be reviewed in bugs.webkit.org). I'd be willing to try any set of steps that accomplishes these tasks. Great. I'll ask you to be a beta tester once we fix Bug 38945. The last time I tried it, webkit-patch was close, but it never quite got there. The ChangeLog seemed to be the main sticking point. Any feedback you have is quite helpful. From my perspective, the tool is done in the sense that it does everything I want it to do. If you want it to do more, please ask. * It didn't handle subdirectory-only work I think here you're refer to the fact that SVN is slow. There was a thread earlier about making webkit-patch operate on the current directory instead of on whole working copy. We can certainly do that if you'd find that helpful. Yes, I'd find it helpful. Slow is one problem. But I also tend to have patches in different parts of the tree -- for example, WebKitTools -- which I don't want to include in my uploaded patch. Ok, I think we've had enough folks ask for this that we should do it. I'll work up a patch and post a separate thread letting people know of the change. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
