The webkit-patch script should support a placeholder for the bug number so that you can create a patch (without having a bug number first), then the ChangeLog gets the correct bug number included just before it lands. This would be similar to the "NOBODY (OOPS!)" placeholder for the reviewer, but would work for the bug number itself. I originally thought the bug number should be replaced in the patch when initially creating the bug, but it would also work to simply insert the bug number when the patch was landed by the commit-queue or by webkit-patch manually. I thought the following placeholders should work (maybe others?): <http://webkit.org/b/00000> <https://bugs.webkit.org/show_bug.cgi?id=00000> This one should probably work as well (although I prefer to have URLs to click on, so I'm okay with leaving it out): Bug 00000
See Bug 57239, Comment #4.
The way I'd approach this is to teach prepare-ChangeLog to add the bug id placeholder and then to have the same code that adds the reviewer replace the placeholder with the real bug id. I'd also put "OOPS" in there somewhere to prevent placeholder bug ids from actually being checked in. Maybe: https://bugs.webkit.org/show_bug.cgi?id=XXXXXX (OOPS! Fill in bug number before landing)
OOPS is so confusing.
Can you tell me more about your workflow? I don't create a bug until after I've written a patch, but then webkit-patch upload creates it for me (right before it asks me to write the ChangeLog). I'm happy to help you make the tools better support whatever workflow you desire. But I'm not sure I understand your workflow yet.
(In reply to comment #4) > Can you tell me more about your workflow? > > I don't create a bug until after I've written a patch, but then webkit-patch upload creates it for me (right before it asks me to write the ChangeLog). I also write the patch first. > I'm happy to help you make the tools better support whatever workflow you desire. But I'm not sure I understand your workflow yet. 1. Write a patch and make it work with tests, etc. 2. Run prepare-ChangeLog and write the entry, including a placeholder for the bug like this: <http://webkit.org/b/00000> Title of the bug goes here 2.5. Branch local repo to commit the fix on a branch. (Sometimes this is Step 0 or Step 1.5.) 3. Run: Tools/Scripts/webkit-patch create-bug --cc=<cc@list> --component="bogus component because I never remember the exact spelling and it prompts me anyway" --no-prompt HEAD So I'm expecting webkit-patch to do (at least) one of the following: - File the bug and then replace the bug number placeholder when uploading the patch. (I don't recall whether webkit-patch mimics the extended HTML form not for uploading a patch with the bug creation.) - Replace the bug number placeholder before landing the patch (which would let me CQ+ the patch if there are no other changes). I would probably use "webkit-patch upload", except it makes me do extra work (like typing in a bug title when it's already in the ChangeLog I just wrote), it makes me write the ChangeLog after I already wrote one (last time I tried it; it's been a few months) and it still doesn't replace the bug number placeholder that I want to use.
OK. So webkit-patch upload was designe to incorporate the prepare-ChangeLog and create-bug steps that you do manually. But I could easily believe that the webkit-patch upload experience is inferior (for your needs) than running prepare-ChangeLog and webkit-patch create-bug manually.
My workflow is thus: 1. Write the patch. 2. Run webkit-patch upload (which prompts me for the bug title, creates the bug, runs prepare-ChangeLog for me, then I write the changelog, and it uploads the patch for me). 3. Commit to my branch. <write my next patch> I often just reset --hard after I've uploaded my patch and use webkit-patch apply-attachment to pull it back down (more of an svn/quilt workflow than a git one). I find that if I make a new branch to start new work I will very often forget my branch that I just uploaded from and have trouble cleaning up branches some months later. :) I commonly have some 50 branchs across my two Git checkouts (on two machines) than I have to wade through to find which patches actually landed vs. didn't. :)
(In reply to comment #7) > My workflow is thus: > > 1. Write the patch. > 2. Run webkit-patch upload (which prompts me for the bug title, creates the bug, runs prepare-ChangeLog for me, then I write the changelog, and it uploads the patch for me). I actually dislike having to write the ChangeLog before running webkit-patch. I feel that I would write inferior ChangeLogs because I'm required to finish before I do any other tasks, and if I do exit early, I have to start all over again, which makes me sad. The latter item is a show-stopper for me. I want "offline" behavior for the "upload" command so I can write my ChangeLogs on my own time, and just use "upload" to, well, upload the patch. It shouldn't be that hard to make webkit-patch know when you already have a ChangeLog for a commit or a patch, and just use it. (I don't expect anyone to implement this for me; I just haven't had time to re-familiarize myself with webkit-patch and Python recently.) > 3. Commit to my branch. > <write my next patch> > > I often just reset --hard after I've uploaded my patch and use webkit-patch apply-attachment to pull it back down (more of an svn/quilt workflow than a git one). I find that if I make a new branch to start new work I will very often forget my branch that I just uploaded from and have trouble cleaning up branches some months later. :) I commonly have some 50 branchs across my two Git checkouts (on two machines) than I have to wade through to find which patches actually landed vs. didn't. :) I rename my branches to start with "bug-NNNNN-" to solve this. Maybe webkit-patch should do that, too! ;)
I apparently did something similar to what was discussed here in bug #161684, "Replace bug URL placeholders independently of the short desc one". Would that be enough to address this bug and, if that's the case, should I merge that bug with this one and update the ChangeLog to point here?