automatic webkit bugzilla bug-posting / management tool
as part of managing 29 patches to webkit i decided to develop a system which parses the ChangeLog entries and re-creates the patches. but - not only that, there's a system for automatic uploading of the patch attachment, as well: http://lkcl.net/webkit/patman it could probably be adapted equally well to work on any bugzilla system, but the Webkit ChangeLog format makes it particularly convenient to use. one of the important things that the patman tool does is re-create the ChangeLog entry at the _top_ of the relevant ChangeLog file, and also it updates the date. then, it goes through looking for the files listed in the ChangeLog, and splits them out of the svn diff (yes, there's a diff/patch parser included in the tool) also, it looks for the first https://bugs.webkit.org entry, parses the number and then spits out the re-formatted patches in to a file patches/patch.<bugnumber>.txt then, if you want to submit the patch as an attachment, run patman/poemposter.py (yes, that's where the code came from - poem posting :) with the following arguments: bugnumber 'bugdescription' [optional review flag - use ? to request review] the [daftly-named] poemposter.py will search for the file patches/patch.{bugnumber}.txt and will upload it automatically to bugs.webkit.org, to the requested bugreport. you will need to create a file login.txt with: user: <email address> pass: <bugzilla password> as this is a bit of a hack-job, you will need to do "svn diff > f" - patman/patchsplit.py doesn't accept any arguments yet, it just assumes that there is a file "f" in the current working directory. also, the tool must be run from the top-level webkit svn. but, it should prove to be incredibly useful to those people submitting bugreports for review, and save a great deal of time. also, the patch-parsing system on its own might prove to be useful for the commit queue processing, as it is capable of splitting out the contents of patches e.g. individual ChangeLog entries. you can see the process by which the ChangeLog entry is re-created as a diff (see use of FakeChangeSet) that is always at the top of the file. l.
Have you looked at WebKitTools/Scripts/bugzilla-tool? There's a lot of overlap between what it does and what you do, but there are definitely (very cool) features in yours that it doesn't have. Maybe you or someone else could try pulling some of this logic into bugzilla-tool? Both are written in Python, so it might not be that hard! J On Sat, Aug 8, 2009 at 11:01 AM, Luke Kenneth Casson Leighton < luke.leighton@googlemail.com> wrote:
as part of managing 29 patches to webkit i decided to develop a system which parses the ChangeLog entries and re-creates the patches. but - not only that, there's a system for automatic uploading of the patch attachment, as well:
it could probably be adapted equally well to work on any bugzilla system, but the Webkit ChangeLog format makes it particularly convenient to use.
one of the important things that the patman tool does is re-create the ChangeLog entry at the _top_ of the relevant ChangeLog file, and also it updates the date.
then, it goes through looking for the files listed in the ChangeLog, and splits them out of the svn diff (yes, there's a diff/patch parser included in the tool)
also, it looks for the first https://bugs.webkit.org entry, parses the number and then spits out the re-formatted patches in to a file patches/patch.<bugnumber>.txt
then, if you want to submit the patch as an attachment, run patman/poemposter.py (yes, that's where the code came from - poem posting :) with the following arguments:
bugnumber 'bugdescription' [optional review flag - use ? to request review]
the [daftly-named] poemposter.py will search for the file patches/patch.{bugnumber}.txt and will upload it automatically to bugs.webkit.org, to the requested bugreport.
you will need to create a file login.txt with: user: <email address> pass: <bugzilla password>
as this is a bit of a hack-job, you will need to do "svn diff > f" - patman/patchsplit.py doesn't accept any arguments yet, it just assumes that there is a file "f" in the current working directory.
also, the tool must be run from the top-level webkit svn.
but, it should prove to be incredibly useful to those people submitting bugreports for review, and save a great deal of time.
also, the patch-parsing system on its own might prove to be useful for the commit queue processing, as it is capable of splitting out the contents of patches e.g. individual ChangeLog entries.
you can see the process by which the ChangeLog entry is re-created as a diff (see use of FakeChangeSet) that is always at the top of the file.
l. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On 8/8/09, Jeremy Orlow <jorlow@chromium.org> wrote:
Have you looked at WebKitTools/Scripts/bugzilla-tool?
*sigh* - nooo :)
There's a lot of overlap between what it does and what you do, but there are definitely (very cool) features in yours that it doesn't have.
Maybe you or someone else could try pulling some of this logic into bugzilla-tool? Both are written in Python, so it might not be that hard!
perhaps it was best that i didn't know it existed, otherwise i might have limited what i decided to do :) ultimately much of these tools should all go into python-bzutils. l.
On 8/8/09, Jeremy Orlow <jorlow@chromium.org> wrote:
Have you looked at WebKitTools/Scripts/bugzilla-tool? There's a lot of overlap between what it does and what you do, but there are definitely (very cool) features in yours that it doesn't have.
another thing that was initially in there, and is commented out right now, well, you can see part of it: changelogextract.py. the reasoning behind this is to migrate from having the ChangeLog text _in_ the ChangeLog to having it in a separate suite of files. the unfortunate thing about ChangeLog is that a) it's a moving target b) it's a _rolling_ moving target. by keeping the entries on a per-patch-group basis separate, you save time and effort esp. when maintaining patches for over a year. l.
participants (2)
-
Jeremy Orlow
-
Luke Kenneth Casson Leighton