Summary: | webkit-patch: Hangs on bad bugzilla username and completes? | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Jerdonek <cjerdonek> | ||||
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | REOPENED --- | ||||||
Severity: | Normal | CC: | abarth, cjerdonek, commit-queue, dbates, eric, joenotcharles | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | All | ||||||
Bug Depends on: | 34265, 34264 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Chris Jerdonek
2010-01-26 18:53:38 PST
Created attachment 47530 [details]
patch to limit number of login attempts
As a first cut, lets cap the number of login attempts so that noninteractive logins don't get stuck if the credentials are wrong
Comment on attachment 47530 [details]
patch to limit number of login attempts
Ok, but it seems like it should prompt you when the stored credentials don't work out.
Comment on attachment 47530 [details] patch to limit number of login attempts Clearing flags on attachment: 47530 Committed r53976: <http://trac.webkit.org/changeset/53976> All reviewed patches have been landed. Closing bug. (In reply to comment #3) > (From update of attachment 47530 [details]) > Clearing flags on attachment: 47530 > > Committed r53976: <http://trac.webkit.org/changeset/53976> Thanks a lot for addressing this so quickly! I mentioned a couple other things though-- > It's bad because there is no line of > output saying anything like "Committed revision...." -- only "Processing > patch 47411 from bug 34060." It's hard to know this means "committed" > because the next output line says it is parsing the Changelog. It seems > like the ChangeLog would be parsed before it starts committing. It > would also be good if the error says what remaining steps didn't > complete, so the user knows what remaining steps need to be manually > completed. And Joe, you acknowledged that this is a "first cut". Could you preserve the other suggestions in a report that is not marked RESOLVED (or alternatively, re-open this one), or explain why the commit makes it unnecessary to address the other suggestions? Thanks a lot. I don't think I can reopen the bug, since I wasn't the submitter (at least, I don't see a link for that anywhere). Can you file a new bug with a "depends on" field for this one, with the title something like "webkit-patch does not clearly state whether it committed or not" since the actual hang has been dealt with? (Or else just reopen this one and change the title, if possible.) This does point out a disturbing lack of atomicity - as I understand it, the patch was landed to svn ok, since your svn login was correct, but then the associated bug wasn't updated in bugzilla, since the bugzilla login was not. Maybe it should login to bugzilla first and not push to svn unless that succeeded? It could still fail if there's a timeout or bugzilla service outage, though I guess the best approach would be, if any step failed, print out a nice big, "WARNING: the following steps were completed: ... But the following were NOT, you need to do them manually: ..." (In reply to comment #6) > I don't think I can reopen the bug, since I wasn't the submitter (at least, I > don't see a link for that anywhere). Can you file a new bug with a "depends > on" field for this one, with the title something like "webkit-patch does not > clearly state whether it committed or not" since the actual hang has been dealt > with? (Or else just reopen this one and change the title, if possible.) > > This does point out a disturbing lack of atomicity - as I understand it, the > patch was landed to svn ok, since your svn login was correct, but then the > associated bug wasn't updated in bugzilla, since the bugzilla login was not. > Maybe it should login to bugzilla first and not push to svn unless that > succeeded? It could still fail if there's a timeout or bugzilla service > outage, though > > I guess the best approach would be, if any step failed, print out a nice big, > "WARNING: the following steps were completed: ... But the following were NOT, > you need to do them manually: ..." Thanks, Joe. I'll go ahead and create new bugs, etc. for you right now. In the meantime, you can ask Maciej (or maybe Eric or someone) to grant you the editbugs privilege so you'll be able to reorganize/edit bugs yourself in the future. (In reply to comment #7) > Thanks, Joe. I'll go ahead and create new bugs, etc. for you right now. See the two bugs this depends on for the two issues remaining before this report should be marked resolved. In general, we prefer to have one patch per bug. Bugs are cheap, so you might as well open new ones instead of reopening old ones. These are all great suggestions, by the way. We're very interested in improving the error handling for webkit-patch. That's one of it's major weak points at the moment. (In reply to comment #9) > In general, we prefer to have one patch per bug. Bugs are cheap, so you might > as well open new ones instead of reopening old ones. I agree with one patch per bug. In addition to reopening this one, I did open two new bugs. I just reopened this one to serve as the master bug for the other two (since it is the original report of all the issues). This report can be closed when the other two are resolved, without submitting further patches to this report. Or you can close this now. Whatever works best for you guys to keep track of the issues. Thanks! It's certainly fine to keep this bug open as a meta bug. I was just spamming with generic advice. Is this still an issue? |