Current state

1 files changed, 205 insertions, 0 deletions

diff --git a/_posts/what-do-i-know-about-the-xorg-bug-triage.rst b/_posts/what-do-i-know-about-the-xorg-bug-triage.rst
new file mode 100644
index 0000000..e6f589d
--- /dev/null
+++ b/_posts/what-do-i-know-about-the-xorg-bug-triage.rst
@@ -0,0 +1,205 @@
+title: Letter to my successors (or what do I know about the Xorg bug triage)
+categories:
+  - bugTriage
+  - computer
+date: 2011-11-22T15:28:36
+tags:
+---
+
+For various reasons we have agreed with my supervisor, that my working
+on the Xorg bug triage as a full time job will be terminated (feels like
+a relief) and I will switch to working as a programmer for the Red Hat
+internal Desktop QA team (which is a good thing!). As the last act in my
+old position I was asked to write down brain dump of my experience
+working on the Xorg bug triage for my potential successors. I am trying
+also to pay some debts I feel I have in documenting some parts of my bug
+triage workflow and tools.
+
+First of all, it is not like there isn't any information available
+already. We as a BugZappers team tried to collect as much information as
+possible so anybody who would like to join our ranks would have
+something to chew upon without us repeating it again and again. So,
+there is `How to Triage`_ page and other pages coming from `this
+navigation page`_ (e.g., you are expected to know `bug workflow`_ by
+heart if drawn in the midnight from your bad).
+
+Queries
+-------
+
+Probably the most important thing which can help you to survive a terror
+of the never-ending inflow of new bugs are well prepared queries. Red
+Hat Bugzilla (or any other bugzilla for that matter, as far as I know),
+doesn't have a really good way to create coarser (or finer) organization
+of bugs than on the level of components and products. The situation is
+especially bad, because products are occupied by, well, products (like
+Fedora, RHEL, etc.), so in fact the only classification of bugs we have
+is on the basis of components. Which is obviously crazy huge group of
+bugs for some components (kernel) and too little for many others. Other
+options (using keywords in whiteboards, for example) requires much
+manual additional work (although we use it as well, see below for Xorg
+bugs categories).
+
+The only way I found how to make dissecting bugs in useful ways possible
+is by using queries. It is normal state of things for me to have more
+than 50 defined queries in the bottom of my bugzilla pages. As an
+example (and possibly foundation of your further development) I could
+present you `this search`_. Notice that it selects just some components
+of bugs (using a regular expression), eliminates bugs with needinfo flag
+set (which is thus a very important variable to care for), and
+eliminates already Triaged bugs. Of course, this is just a basic search
+which can be further narrowed by selecting only bugs in some states
+(although bug triagers deal mostly with NEW bugs), bugs changed in the
+recent time (when the time is short, it is probably better to deal with
+the active bugs, not stale ones), bugs for some versions of products,
+etc.
+
+Firefox addon
+-------------
+
+Although there has been concerned spent lately on making bugzilla work
+better for developers, it is still true that its user interface is (if
+for anybody) optimized for users and so there is little help for
+avoiding repetitive work. In order to make my work with bugzilla more
+palatable, I have created a Firefox addon which provides tools for
+mechanizing a lot of stereotypic work. For example, reporters in the Red
+Hat bugzilla have no meaningful guidance when filing Xorg bugs, so many
+filed bugs are lacking logs and other information which is required for
+developers to effectively diagnose the issue. Actually, making sure that
+all this information is provided is the main task of Xorg bug triage
+(where normal other tasks of bug triage, e.g., deduplication and testing
+reproducers is hardly possible or completely impossible given the limits
+on available hardware and knowledge of the code itself).
+
+Back to the firefox addon. The main functionality has been described on
+this blog, so just in the way of summary. The main point which you need
+to understand is that almost all functionality can be controlled and
+substantially changed by editing a JSON file which is loaded on the
+startup of the addon. Per default it is `this JSON`_, but clicking on
+“Triage configuration” link you can enter URL of any JSON file anywhere
+on the Internet. All possible options are switched on in `my JSON`_,
+which can be used as an example for developing of your own file. Let me
+go through the main options available in such file.
+
+Most famous and probably still most used are buttons filling
+standardized comments. That's the biggest parts of JSON file in the
+object (using Javascript terminology) commentPackages. The name evokes
+that there are multiple packages which can be switched on for particular
+bugzillas (one bug triager can certainly work on multiple bugzilla
+instances ... see configData.enabledPackages for examples how to switch
+on some packages for particular bugzillas). Each packages contains
+multiple objects one for each button which looks like this::
+
+   "addnoresponse": {
+              "name": "NoRespns",
+              "position": "topRow",
+              "commentIdx": "noResponseString",
+              "markTriaged": true,
+              "status": "CLOSED",
+              "resolution": "INSUFFICIENT_DATA"
+         },
+
+Each object has its own one-word name, which serves as an index and id
+for the button itself. Each object is best understood as a package of
+commands which will be executed when the button is pressed. Some of
+these “commands” actually don’t are not commands but metadata ("name"
+contains the label on the button, "position" shows to the addon where
+the button should be located), but most of them actually do something.
+So in this example, “commentIdx” points to the comment string in
+“commentString” section of the JSON file. For shorter comment texts,
+button package can contain directly “comment” property with the text
+itself. Either of these texts can be included in the comment.
+“markTriaged” will obviously make all necessary steps to make bug
+triaged, and the remaining two commands will close the bug. “position”
+deserves a little bit special treatment. It can be either “topRow” or
+“bottomRow” which means that the button will be inserted into the row of
+buttons above or below the comment box respectively. “position” property
+can also contain the ID of the element after or before which the button
+should be included (such string starts with “+” or “-” before the ID
+string). So for example, “addexternalbugid” package contains
+``"position": "+external_bugs_headline",`` which means that the button
+should follow HTML element with “external\_bugs\_headline” ID.
+
+After “commentPackages” and “commentStrings” sections, the next one is
+“configData” which is a collection of various configuration options. I
+have in my JSON file almost all of possible ones on. I will return to
+this configuration section in a minute, but now let me just the mention
+the last section “constantData” which contains various constants for
+Xorg bug triagers, and which you should probably just take for your
+JSON.
+
+Back to the “configData” section. The biggest object (at least in my
+file) is “killNodes” which is an object which for each bugzilla instance
+where the triager is supposed to work lists IDs of all elements you
+would like to remove from the page (some people especially from Mozilla
+complained that there is just too much stuff on every page, so that for
+some people the bugzilla is almost useless, but I had to admit I used it
+well even with bugzilla.redhat.com). “downloadJSON” contains URLs for
+additional data files which can be loaded for data which are just too
+big to be included into “constantData” section (take a look at `that
+file`_). “suspiciousComponents” is for situations when reporters
+continuously file bugs into components which are there just for legacy
+or organizational reasons (``xorg-x11`` and ``xorg-x11-drivers``). The
+last is set of couple of Booleans, which directly allow some features of
+the addon, which are usually not useful for “normal” bug triagers, but
+were useful for me:
+
+parseAbrtBacktraces
+    This is mostly legacy option, for large piece of functionality,
+    which pulled just a important part of backtrace from the attached
+    abrt-produced log.
+
+submitsLogging
+    This is a switch for a functionality which is completely useless for
+    anybody who is not hired for being a bug triager. This addons could
+    ask you for every click on the Submit button to provide short
+    message, which could be then collated into something which goes to
+    my weekly status report. Obviously it should be set to ``false`` for
+    almost everybody.
+
+verboseInlineHistory
+    This is a switch for unfinished attempt to merge in functionality
+    from `Bugzilla Tweaks`_ `functionality of which`_ was `later
+    included into the upstream bugzilla itself`_.
+
+XorgLogAnalysis
+    This is a tool which could be very useful for any Xorg bug triager.
+    However, it is kind of dangerous, because if misused it could lead
+    to quite sloppy work. What it does is that it adds to every
+    Xorg.0.log (and dmesg output) a button which makes the addon to run
+    the log through regular expressions which selects lines which can be
+    interesting.  Obviously it is useful for fast overview of what's
+    going on, but certainly detailed inspection of the log is required
+    for any decision.
+
+So, this is finally written down documentation for the mythical JSON
+file, which I promised for so long.
+
+A bit on process of treating a bug
+----------------------------------
+
+I will skip technical issues (they are described reasonably well on the
+above mentioned BugZappers pages), but let me add here couple of notes
+on the background of the process. First of all, although bug triage is
+kind of lonely job, we stand on shoulders of some giants (or at least we
+could if we knew about them). Luis Villa (former bugmaster of Ximian and
+Gnome project) has `a nice collection of his presentations and talks`_.
+Highly recommended. Also a lot of discussion about bugs management
+(obviously) happens in the Bugzilla community, for which `Bugzilla
+Planet`_ is a great entry point (or you can go all the way to `Mozilla
+Planet`_)
+
+(... to be continued ...)
+
+.. _`How to Triage`: https://fedoraproject.org/wiki/BugZappers/How_to_Triage
+.. _`this navigation page`: https://fedoraproject.org/wiki/BugZappers
+.. _`bug workflow`: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
+.. _`this search`: https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=all%20NEW&sharer_id=74116
+.. _`this JSON`: https://fedorahosted.org/released/bugzilla-triage-scripts/Config_data.json
+.. _`my JSON`: http://matej.ceplovi.cz/progs/data/RH_Data-packages.json
+.. _`that file`: http://matej.ceplovi.cz/progs/data/chipNames.json
+.. _`Bugzilla Tweaks`: http://ehsanakhgari.org/blog/2010-05-31/my-experience-jetpack-sdk
+.. _`functionality of which`: http://ehsanakhgari.org/blog/2010-01-07/bugzilla-tweaks-enhanced
+.. _`later included into the upstream bugzilla itself`: http://globau.wordpress.com/2011/08/23/bugzilla-inline-history-extension/
+.. _`a nice collection of his presentations and talks`: http://tieguy.org/talks/
+.. _`Bugzilla Planet`: http://planet.bugzilla.org/
+.. _`Mozilla Planet`: http://planet.mozilla.org