{"id":300,"date":"2012-01-05T16:31:25","date_gmt":"2012-01-06T00:31:25","guid":{"rendered":"http:\/\/blog.mozilla.org\/sfink\/?p=300"},"modified":"2021-06-13T14:10:19","modified_gmt":"2021-06-13T21:10:19","slug":"patch-queue-dependencies","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/sfink\/2012\/01\/05\/patch-queue-dependencies\/","title":{"rendered":"patch queue dependencies"},"content":{"rendered":"<p>A little while back, I was again contemplating a tangled patch queue, considering how to rework it for landing. I thought it&#8217;d be nice to see at a very basic level which patches in the queue were going to be problematic, and which I could freely reorder at whim.<\/p>\n<p>So I whipped together a <a href='http:\/\/people.mozilla.org\/~sfink\/data\/patchdeps'>silly little script<\/a> to do that at a file level only. Example output:<\/p>\n<pre>\r\n% patchdeps\r\nNote: This is based on filename collisions only, so may overreport conflicts\r\nif patches touch different parts of the same file. (TODO)\r\n                                                                          \r\nA bug-663281-deque                   X   *       *     *   * *     *      \r\nA bug-663281-deque-test              |   :       :     :   : *     :      \r\nA bug-642054-func-setline          X |   *       :     :   : :     :      \r\nA bug-642054-js_MapPCToLineNumber--' |   *       :     :   : :     :      \r\nA bug-642054-rwreentrant             |   : X     :     :   : :     :      \r\nA algorithm--------------------------'   X |     *     *   * *     *      \r\nA system-libunwind                     X | |     :   * : * : *   * :      \r\nA try-libunwind------------------------' | |     :   X : * : *   * :      \r\nA backtrace------------------------------' | X * * * | * : * * * : * * * *\r\nU shell-backtrace                          | | : * : | : : : : : : : : : :\r\nU M-reentr---------------------------------' | : : : | : : : : : : : : : :\r\nU M-backtrace--------------------------------' X : : | : : : : : : : * : :\r\nU activities-----------------------------------' X : | : : : : * * : X * *\r\nU profiler---------------------------------------' X | * : * * X * * | * *\r\nU bug-675096-valgrind-jit--------------------------' | * : * : | : : | : :\r\nU bug-599499-opagent-config--------------------------' X * : * | * : | : :\r\nU bug-599499-opagent-----------------------------------' X X * | : * | : :\r\nU bug-642320-gdb-jit-config------------------------------' | * | * : | : :\r\nU bug-642320-gdb-jit---------------------------------------' X | : * | : :\r\nU import-libunwind                                           | | : : | : :\r\nU libunwind-config-------------------------------------------' | X X | : :\r\nU warnings-fixes-----------------------------------------------' | | | : *\r\nU bug-696965-cfi-autocheck---------------------------------------' | | X :\r\nU mystery-librt-stuff----------------------------------------------' | | :\r\nU bug-637393-eval-lifetime                                           | | :\r\nU register-dwarf-----------------------------------------------------' | :\r\nU bug-652535-JM__JIT_code_performance_counters-------------------------' X\r\nU JSOP_RUNMODE-----------------------------------------------------------'\r\n<\/pre>\n<p>How to read it: patches that have no conflicts earlier in the stack are shown without a line next to them. They&#8217;re free spirits; you can &#8220;sink&#8221; them anywhere earlier in your queue without getting conflicts. (The script removes their lines to make the grid take up less horizontal space.)<\/p>\n<p>Any other patch gets a horizontal line that then bends up to show the interference pattern with earlier patches. All in all, you have a complete interference matrix showing whether the set of files touched by any patch intersects the set of files for any other patch.<\/p>\n<p>&#8216;X&#8217; marks the first conflict. After that, the marker turns to &#8216;*&#8217; and the vertical lines get broken. (That&#8217;s just because it&#8217;s mostly the first one that matters when you&#8217;re munging your queue.)<\/p>\n<p>So the patch named &#8220;backtrace&#8221; conflicts with the earlier &#8220;algorithm&#8221; patch, as well as the even earlier &#8220;bug-642054-js_MapPCToLineNumber&#8221; and others. The &#8220;M-reentr&#8221; patch only touches the same stuff as &#8220;bug-642054-rwreentrant&#8221; (not surprising, since &#8220;M-&#8230;&#8221; is my notation for a patch that needs to be folded into an earlier patch.) &#8220;system-libunwind&#8221; doesn&#8217;t conflict with anything earlier in the queue, and so can be freely reordered in the series file to anywhere earlier than where it is now &#8212; but note that several later patches touch the same stuff as it does. (It happens to be a patch to js\/src\/configure.in.)<\/p>\n<p>Useful? Not very. But it was kinda fun to write and I find myself running it occasionally just to see what it shows, so I feel the entertainment value was worth the small investment of time. Though now I&#8217;m tempted to enhance it by checking for collisions in line ranges, not just in the files&#8230;<\/p>\n<p>I suppose I could make a mercurial extension out of it, but that&#8217;d require porting it from Perl to Python, which is more trouble than it&#8217;s worth. (Yes, I still use Perl as my preferred language for whipping things together. Even though I dislike the syntax for nested data structures, I very much like the feature set, and it&#8217;s still the best language I&#8217;ve found for these sorts of things. So phbbbttt!)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A little while back, I was again contemplating a tangled patch queue, considering how to rework it for landing. I thought it&#8217;d be nice to see at a very basic level which patches in the queue were going to be problematic, and which I could freely reorder at whim. So I whipped together a silly [&hellip;]<\/p>\n","protected":false},"author":206,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[477,289,137],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/posts\/300"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/users\/206"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/comments?post=300"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/posts\/300\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/media?parent=300"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/categories?post=300"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/tags?post=300"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}