Howdy folks,
I put together some code to fetch all the non-obsolete patches from this page and see if they apply against trunk. https://bugzilla.wikimedia.org/buglist.cgi?keywords=patch%2C%20need-review&a...
Basically it tries --strip with 0,1,2,3 and then does an exhaustive search of the tree for places where the patch might apply.
These are my results. http://pastebin.com/tgNTfXzx
For ease of viewing, here is a list filtered to only the successfully applied patches. http://pastebin.com/EGA3cF90
The "Strip" and "Path" information is what you need to apply the patch. (eg. patch --directory=includes/ --strip 3 < mypatchfile)
Eventually I may update these scripts to run all the automated tests on each patch that apply cleanly. However, I won't be getting to it in the near future. ;-)
In the meantime, hopefully this makes it easier to catch up on the backlog.
If anyone wants to mess with the code (it is in Ruby), please let me know and I will get it up on GitHub.
~Rusty
On 14/11/11 00:00, Rusty Burchfield wrote:
Howdy folks,
I put together some code to fetch all the non-obsolete patches from this page and see if they apply against trunk.
Wow, thanks
https://bugzilla.wikimedia.org/buglist.cgi?keywords=patch%2C%20need-review&a...
Basically it tries --strip with 0,1,2,3 and then does an exhaustive search of the tree for places where the patch might apply.
These are my results. http://pastebin.com/tgNTfXzx
There seems to be bugs in that list that are already closed. (Should need-review be removed from those bugs?) Manually running that query, I see 218 bugs, 240 on your list. Indeed, I don't see how did your script get to https://bugzilla.wikimedia.org/show_bug.cgi?id=8627 (plus determine that it contained a valid patch).
Eventually I may update these scripts to run all the automated tests on each patch that apply cleanly. However, I won't be getting to it in the near future. ;-)
In the meantime, hopefully this makes it easier to catch up on the backlog.
If anyone wants to mess with the code (it is in Ruby), please let me know and I will get it up on GitHub.
~Rusty
Not the best candidate language for us :/
Platonides <Platonides <at> gmail.com> writes:
On 14/11/11 00:00, Rusty Burchfield wrote:
These are my results. http://pastebin.com/tgNTfXzx
There seems to be bugs in that list that are already closed. (Should need-review be removed from those bugs?) Manually running that query, I see 218 bugs, 240 on your list. Indeed, I don't see how did your script get to https://bugzilla.wikimedia.org/show_bug.cgi?id=8627 (plus determine that it contained a valid patch).
Please read the details at the top of the pastebin. ;-)
The Patch number is an attachment ID not a bug ID. There are multiple patches on some bugs so they show up as multiple lines in the list.
Also, Reedy resolved one of the bugs after I compiled the list (there were 219).
If anyone wants to mess with the code (it is in Ruby), please let me know and I will get it up on GitHub.
Not the best candidate language for us :/
Sorry, PHP won't ever be my first choice for fun projects. I won't be hurt if no one is interested in hacking on it.
BTW, if you reply-all it is a lot easier for people in digest mode to respond. :-)
~Rusty
* Rusty Burchfield wrote:
BTW, if you reply-all it is a lot easier for people in digest mode to respond. :-)
(Actually, since the Reply-To header takes the place of the From address and the only other address is in the To header, and the two headers are the same on lists that manipulate the Reply-To header, many clients will just reply to the list even if the user elects to "reply-all".)
Rusty Burchfield gicodewarrior@gmail.com writes:
If anyone wants to mess with the code (it is in Ruby), please let me know and I will get it up on GitHub.
I'd like to see exactly what you're doing and port it to my bz framework. Please post it!
Mark A. Hershberger <mhershberger <at> wikimedia.org> writes:
Rusty Burchfield <gicodewarrior <at> gmail.com> writes:
If anyone wants to mess with the code (it is in Ruby), please let me know and I will get it up on GitHub.
I'd like to see exactly what you're doing and port it to my bz framework. Please post it!
Here you go: https://github.com/GICodeWarrior/patch-tester
It is a hack right now, but if you don't obsolete it with your framework I may improve it. ;-)
Basically I fetch pages with curb(libcurl) and pull out what I need with nokogiri(libxml2) and some css selectors. Then I take each patch and attempt an exhaustive search (after trying the easy cases) to see if it will apply.
I started with the Bugzilla API, but it was pretty annoying so I took the "easy" route.
In at least one case it appears to have found a way to apply a really old patch against a file that was actually moved within the tree. :-)
~Rusty
On 14/11/11 23:28, Rusty Burchfield wrote:
Mark A. Hershberger <mhershberger <at> wikimedia.org> writes:
Rusty Burchfield <gicodewarrior <at> gmail.com> writes:
If anyone wants to mess with the code (it is in Ruby), please let me know and I will get it up on GitHub.
I'd like to see exactly what you're doing and port it to my bz framework. Please post it!
Here you go: https://github.com/GICodeWarrior/patch-tester
It is a hack right now, but if you don't obsolete it with your framework I may improve it. ;-)
Is ruby code always so verbose? I expected one or two files, not 54! Where is the real code?
On Mon, Nov 14, 2011 at 4:13 PM, Platonides Platonides@gmail.com wrote:
On 14/11/11 23:28, Rusty Burchfield wrote:
Here you go: https://github.com/GICodeWarrior/patch-tester
It is a hack right now, but if you don't obsolete it with your framework I may improve it. ;-)
Is ruby code always so verbose? I expected one or two files, not 54! Where is the real code?
To make it easier to hack around, it is in a Rails project.
As noted in the README, the interesting stuff is in "extras/". $ find extras/ -type f | xargs wc -l 56 extras/bugzilla/patch.rb 25 extras/bugzilla/bug.rb 15 extras/bugzilla/attachment.rb 33 extras/bugzilla/site.rb 2 extras/bugzilla.rb 131 total
~Rusty
wikitech-l@lists.wikimedia.org