{"id":307,"date":"2012-01-21T22:36:34","date_gmt":"2012-01-22T06:36:34","guid":{"rendered":"http:\/\/blog.mozilla.org\/sfink\/?p=307"},"modified":"2021-06-13T14:10:19","modified_gmt":"2021-06-13T21:10:19","slug":"bzexport-new-crash-test-dummies-wanted","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/sfink\/2012\/01\/21\/bzexport-new-crash-test-dummies-wanted\/","title":{"rendered":"bzexport &#8211;new: crash test dummies wanted"},"content":{"rendered":"<p>Scenario 1: you have a patch to some bug sitting in our mercurial queue. You want to attach it to a bug, but the bugzilla interface is painful and annoying. What do you do?<\/p>\n<p>Use <a href=\"http:\/\/hg.mozilla.org\/users\/tmielczarek_mozilla.com\/bzexport\">bzexport<\/a>. It&#8217;s great! You can even request review at the same time.<\/p>\n<p>What I really like about bzexport is that while writing and testing a patch, I&#8217;m in an editor and the command line. I may not even have a browser running, if I&#8217;m constantly re-starting it to test something out. Needing to go to the bugzilla web UI interrupts my flow. With bzexport, I can stay in the shell and move onto something else immediately.<\/p>\n<p>Scenario 2: You have a patch, but haven&#8217;t filed a bug yet. Neither has anybody else. But your patch has a pretty good description of what the bug is. (This is common, especially for small things.) Do you really have to go through the obnoxious bug-filing procedure? It sure is tempting just to roll this fix up into some other vaguely related bug, isn&#8217;t it? Surely there&#8217;s a simple way to do things the right way without bouncing between interfaces?<\/p>\n<p>Well, you&#8217;re screwed. Unless you&#8217;re willing to test something out for me. If not, please stop reading.<br \/>\n<!--more--><\/p>\n<hr \/>\n<p>Great! You&#8217;re still here! Ok, give <a href=\"https:\/\/bitbucket.org\/sfink\/bzexport\/\">this modified version of bzexport<\/a> a try. (<strong>Update:<\/strong><em> everything described in this post is now available in the<\/em> <a title=\"bzexport\" href=\"http:\/\/hg.mozilla.org\/users\/tmielczarek_mozilla.com\/bzexport\/\">official version of bzexport<\/a>.)\u00a0 It adds a <tt>--new<\/tt> option to the <tt>hg bzexport<\/tt> command that creates a new bug, then attaches your patch to it. My preferred way to use it, for a bug in the Javascript engine (product &#8216;Core&#8217;, component &#8216;JavaScript engine&#8217;):<\/p>\n<p><tt>hg bzexport --new -e -i -C javascript<\/tt><\/p>\n<p>That&#8217;ll grab off the top applied patch in your mercurial queue. The first line of its description (as set by <tt>hg qnew -e<\/tt> or <tt>hg qref -e<\/tt>) will be used for the bug title and the patch description; any other lines will be used for bug comments. It&#8217;ll create a bug, upload your patch as an attachment, and wash your car.<\/p>\n<p>In case you only own a bicycle or your car is allergic to soap, here&#8217;s some detail on all those options I passed:<\/p>\n<ul>\n<li><tt>--new<\/tt>: Create a new bug to attach your patch to. (Without this, it would use the existing bug given either on the command line or in the patch description.)<\/li>\n<li><tt>-e<\/tt>(or &#8211;edit): Open up your text editor on a textual form where you can fill in all of the various values: bug title, product, component, comments, etc. If you omit this, it will prompt for anything it needs, but I prefer using this option to see everything at once.<\/li>\n<li><tt>-i<\/tt>(or &#8211;interactive): That&#8217;s a lot of magic, and I know the idiot who wrote this code, so I want to be asked before it does anything irreversible. In this case, it&#8217;ll ask before creating the bug, and before uploading the attachment. I can cancel at any time.<\/li>\n<li><tt>-C javascript<\/tt> (or &#8211;component javascript): This is for setting the product and component. You <em>could<\/em> say <tt>-C 'Core\/JavaScript Engine'<\/tt> if you happen to have your product\/component memorized. Or even <tt>--product Core --component 'JavaScript Engine'<\/tt> if you really like being explicit. But if you&#8217;re as lazy as I am, you can give a substring of just your component, and bzexport will scan through all components of all products and find substring matches. In this case, there is a unique match, and it&#8217;ll fill everything in for you. It Does The Right Thing if there are multiple matches &#8212; if you give the -e option, you&#8217;ll have a second chance to tell it the product and component, and if you still can&#8217;t be bothered (or you didn&#8217;t use the -e option in the first place), it will present a textual menu giving all of your options. For example, if I had said <tt>-C engine<\/tt>, it would give me a menu of the 4 products containing components with &#8220;engine&#8221; as a substring. If I foolishly chose &#8216;Mozilla Messaging&#8217;, it would set the product\/component to &#8216;Mozilla Messaging\/Release <strong>Engine<\/strong>ering&#8217;, which is not at all what I wanted but might be if you are not me.<\/li>\n<\/ul>\n<p>If you demand even more help in choosing a bugzilla product and component, install my <a href=\"https:\/\/bitbucket.org\/sfink\/mqext\">mqext<\/a> extension and run <tt>hg components<\/tt> (or perhaps <tt>hg components -f <em>filename<\/em><\/tt>) to scan through the last 100k commits or so and look for the product\/component of all bugs that touched the same files to provide a best guess as to the appropriate categorization.<\/p>\n<p>So where do you come in? Why am I babbling on about this instead of just getting it reviewed by the maintainer (jdm), landing it, and shutting up?<\/p>\n<p>Well, I did give jdm an earlier version, and he mostly liked it. But like I said, it&#8217;s a lot of magic (more than I went over above &#8212; there&#8217;s stuff for picking reviewers, possibly from the patch description, and setting a product version). It implements one particular workflow that I dreamt up. It makes sense to me, but I figure that other people probably have rather different ideas of how it should work and will be rather irritated by what I came up with. I&#8217;m not sure if all of this is 100% compatible with the previous bzexport workflow, so I&#8217;d like to be a little more confident that this is the right direction before updating what everybody&#8217;s using.<\/p>\n<p>So please, especially if you&#8217;re an irritable person, give it a try and let me know what you think. It scratches my itch, but I&#8217;d like to try to scratch your itch too.<\/p>\n<p>Figuratively, I mean.<\/p>\n<p>Yuck.<\/p>\n<p>How can I get that mental image out of my head? Argh!!<\/p>\n<p>Anyway, one last thing &#8212; there&#8217;s also an <tt>hg newbug<\/tt> command in case you just want the bug-creation functionality, or want to do things in isolated steps. You still get all of the cookie-stealing goodness from bzexport (it&#8217;s awesome; it rifles around your Firefox default profile directory, tries to find the database containing your bugzilla cookie, does some funky magic to open it even if it&#8217;s locked down by sqlite&#8217;s WAL feature, and snatches away the cookie to use for your bugzilla operations. ted++.)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Scenario 1: you have a patch to some bug sitting in our mercurial queue. You want to attach it to a bug, but the bugzilla interface is painful and annoying. What do you do? Use bzexport. It&#8217;s great! You can even request review at the same time. What I really like about bzexport is that [&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":[228,477,666,4139,4145,137,610],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/posts\/307"}],"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=307"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/posts\/307\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/media?parent=307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/categories?post=307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/sfink\/wp-json\/wp\/v2\/tags?post=307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}