<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>137483</bug_id>
          
          <creation_ts>2014-10-07 04:27:16 -0700</creation_ts>
          <short_desc>[webkitpy] CQ- should mean not valid patch for commit queue</short_desc>
          <delta_ts>2017-06-20 02:16:50 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>New Bugs</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>NEW</bug_status>
          <resolution></resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Csaba Osztrogonác">ossy</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>ap</cc>
    
    <cc>commit-queue</cc>
    
    <cc>dbates</cc>
    
    <cc>glenn</cc>
    
    <cc>jake.nielsen.webkit</cc>
    
    <cc>ossy</cc>
    
    <cc>rniwa</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1039999</commentid>
    <comment_count>0</comment_count>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2014-10-07 04:27:16 -0700</bug_when>
    <thetext>[webkitpy] CQ- should mean not valid patch for commit queue</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040000</commentid>
    <comment_count>1</comment_count>
      <attachid>239406</attachid>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2014-10-07 04:33:06 -0700</bug_when>
    <thetext>Created attachment 239406
Patch

I found this bug during working on bug137460. Now the commit queue doesn&apos;t refuse the patch marked with cq- during processing, but not obsoleted or closed the bug. cq- should mean not valid too to make cq refuse the patch during the the second validation phase just before landing.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040038</commentid>
    <comment_count>2</comment_count>
      <attachid>239406</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2014-10-07 09:44:32 -0700</bug_when>
    <thetext>Comment on attachment 239406
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=239406&amp;action=review

&gt; Tools/Scripts/webkitpy/tool/bot/commitqueuetask.py:54
&gt; +        if self._patch.commit_queue() == &quot;-&quot;:
&gt; +            return False

What code checks that flag hasn&apos;t been changed back to &quot;cq?&quot;? Perhaps there is a separate check somewhere that cq+ is still set?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040040</commentid>
    <comment_count>3</comment_count>
      <attachid>239406</attachid>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2014-10-07 09:55:20 -0700</bug_when>
    <thetext>Comment on attachment 239406
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=239406&amp;action=review

&gt;&gt; Tools/Scripts/webkitpy/tool/bot/commitqueuetask.py:54
&gt;&gt; +            return False
&gt; 
&gt; What code checks that flag hasn&apos;t been changed back to &quot;cq?&quot;? Perhaps there is a separate check somewhere that cq+ is still set?

Good point, there isn&apos;t a separate check for it.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040043</commentid>
    <comment_count>4</comment_count>
      <attachid>239414</attachid>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2014-10-07 10:03:03 -0700</bug_when>
    <thetext>Created attachment 239414
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040049</commentid>
    <comment_count>5</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2014-10-07 10:35:57 -0700</bug_when>
    <thetext>Yesterday evening, I saw a patch that was endlessly spinning in exactly this situation - it was marked cq+ at first, then back cq?.

Commit queue started, then bailed out, then started to go in circles very quickly. This tells me that there is already a check somewhere that was (temporarily) rejecting patches with cq? form commit queue.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040079</commentid>
    <comment_count>6</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2014-10-07 12:08:07 -0700</bug_when>
    <thetext>I tried to find any such checks, and couldn&apos;t. Maybe I&apos;m confused, and commit queue happily lands anything with cq-? And we didn&apos;t notice that over all those years?

Started an experiment in bug 137492.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040109</commentid>
    <comment_count>7</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2014-10-07 13:17:06 -0700</bug_when>
    <thetext>So looks like cq- already prevents landing.

Looking through the code again, it appears that the check is under here:

        if not self._patch.committer():
            return False

committer() is only present when cq+ is set, see _parse_attachment_flag in bugzilla.py:

    def _parse_attachment_flag(self,
                               element,
                               flag_name,
                               attachment,
                               result_key):
        flag = element.find(&apos;flag&apos;, attrs={&apos;name&apos;: flag_name})
        if flag:
            attachment[flag_name] = flag[&apos;status&apos;]
            if flag[&apos;status&apos;] == &apos;+&apos;:
                attachment[result_key] = flag[&apos;setter&apos;]

We should probably add a comment explaining that.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040110</commentid>
    <comment_count>8</comment_count>
      <attachid>239414</attachid>
    <who name="Ryosuke Niwa">rniwa</who>
    <bug_when>2014-10-07 13:20:12 -0700</bug_when>
    <thetext>Comment on attachment 239414
Patch

Oops, cq-ing this per ap&apos;s comment.

Please resolve the remaining issue with the patch as commented by ap before landing this.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040125</commentid>
    <comment_count>9</comment_count>
      <attachid>239414</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2014-10-07 13:48:02 -0700</bug_when>
    <thetext>Comment on attachment 239414
Patch

I think that the patch is good, except that we need to replace the code change with a comment. And maybe fix the mock implementation to more closely match the actual one, so that it tests the right thing.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040128</commentid>
    <comment_count>10</comment_count>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2014-10-07 14:07:29 -0700</bug_when>
    <thetext>(In reply to comment #7)
&gt; So looks like cq- already prevents landing.
&gt; 
&gt; Looking through the code again, it appears that the check is under here:
&gt; 
&gt;         if not self._patch.committer():
&gt;             return False
&gt; 
&gt; committer() is only present when cq+ is set, see _parse_attachment_flag in bugzilla.py:
&gt; 
&gt;     def _parse_attachment_flag(self,
&gt;                                element,
&gt;                                flag_name,
&gt;                                attachment,
&gt;                                result_key):
&gt;         flag = element.find(&apos;flag&apos;, attrs={&apos;name&apos;: flag_name})
&gt;         if flag:
&gt;             attachment[flag_name] = flag[&apos;status&apos;]
&gt;             if flag[&apos;status&apos;] == &apos;+&apos;:
&gt;                 attachment[result_key] = flag[&apos;setter&apos;]
&gt; 
&gt; We should probably add a comment explaining that.

Good catch, it is so hidden check. :) I&apos;ll add a comment and fix the mock too.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1040131</commentid>
    <comment_count>11</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2014-10-07 14:33:54 -0700</bug_when>
    <thetext>Jake suggested that maybe we can replace the mysterious check with your one. With a cursory look over the code, it seems like it may just work.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>239406</attachid>
            <date>2014-10-07 04:33:06 -0700</date>
            <delta_ts>2014-10-07 10:02:55 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-137483-20141007133307.patch</filename>
            <type>text/plain</type>
            <size>2123</size>
            <attacher name="Csaba Osztrogonác">ossy</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMTc0Mzg5CmRpZmYgLS1naXQgYS9Ub29scy9DaGFuZ2VMb2cg
Yi9Ub29scy9DaGFuZ2VMb2cKaW5kZXggMTE0NjcwMmQxMzE4Y2NlYWM2ZTY5MTc0Yjg0NGE1ZWQ2
M2MyZGMxNS4uZjhkYWZmOTA1OWQxYmE2NWMxMDFkNmY0MDhjOTlhMmNjZjYzODUwZiAxMDA2NDQK
LS0tIGEvVG9vbHMvQ2hhbmdlTG9nCisrKyBiL1Rvb2xzL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE1
IEBACisyMDE0LTEwLTA3ICBDc2FiYSBPc3p0cm9nb27DoWMgIDxvc3N5QHdlYmtpdC5vcmc+CisK
KyAgICAgICAgW3dlYmtpdHB5XSBDUS0gc2hvdWxkIG1lYW4gbm90IHZhbGlkIHBhdGNoIGZvciBj
b21taXQgcXVldWUKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dp
P2lkPTEzNzQ4MworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAg
ICAgICogU2NyaXB0cy93ZWJraXRweS90b29sL2JvdC9jb21taXRxdWV1ZXRhc2sucHk6CisgICAg
ICAgIChDb21taXRRdWV1ZVRhc2sudmFsaWRhdGUpOgorICAgICAgICAqIFNjcmlwdHMvd2Via2l0
cHkvdG9vbC9ib3QvY29tbWl0cXVldWV0YXNrX3VuaXR0ZXN0LnB5OgorICAgICAgICAodGVzdF92
YWxpZGF0ZSk6CisKIDIwMTQtMTAtMDYgIFJ5b3N1a2UgTml3YSAgPHJuaXdhQHdlYmtpdC5vcmc+
CiAKICAgICAgICAgTWFrZSB3ZWJraXQtcGF0Y2ggZmluZC11c2VycyB1c2VmdWwKZGlmZiAtLWdp
dCBhL1Rvb2xzL1NjcmlwdHMvd2Via2l0cHkvdG9vbC9ib3QvY29tbWl0cXVldWV0YXNrLnB5IGIv
VG9vbHMvU2NyaXB0cy93ZWJraXRweS90b29sL2JvdC9jb21taXRxdWV1ZXRhc2sucHkKaW5kZXgg
YTk1YzdiMTAzYTE1YWU4ZjdmMjc5NmIyZGVmZmI0M2MyNGZmNzY5Zi4uMTIwMzdmYWNjYjg5NTAw
OTg2OTZjZTU1N2FkY2E0ZjZmZDVjOTFiMCAxMDA2NDQKLS0tIGEvVG9vbHMvU2NyaXB0cy93ZWJr
aXRweS90b29sL2JvdC9jb21taXRxdWV1ZXRhc2sucHkKKysrIGIvVG9vbHMvU2NyaXB0cy93ZWJr
aXRweS90b29sL2JvdC9jb21taXRxdWV1ZXRhc2sucHkKQEAgLTUwLDYgKzUwLDggQEAgY2xhc3Mg
Q29tbWl0UXVldWVUYXNrKFBhdGNoQW5hbHlzaXNUYXNrKToKICAgICAgICAgICAgIHJldHVybiBG
YWxzZQogICAgICAgICBpZiBzZWxmLl9wYXRjaC5yZXZpZXcoKSA9PSAiLSI6CiAgICAgICAgICAg
ICByZXR1cm4gRmFsc2UKKyAgICAgICAgaWYgc2VsZi5fcGF0Y2guY29tbWl0X3F1ZXVlKCkgPT0g
Ii0iOgorICAgICAgICAgICAgcmV0dXJuIEZhbHNlCiAgICAgICAgIHJldHVybiBUcnVlCiAKICAg
ICBkZWYgX3ZhbGlkYXRlX2NoYW5nZWxvZyhzZWxmKToKZGlmZiAtLWdpdCBhL1Rvb2xzL1Njcmlw
dHMvd2Via2l0cHkvdG9vbC9ib3QvY29tbWl0cXVldWV0YXNrX3VuaXR0ZXN0LnB5IGIvVG9vbHMv
U2NyaXB0cy93ZWJraXRweS90b29sL2JvdC9jb21taXRxdWV1ZXRhc2tfdW5pdHRlc3QucHkKaW5k
ZXggZGM0ZTNkM2VmNTg4MWVkODNjNjEzODcwYzc4YjM3ZGFmZDY4ODI3Ny4uN2VjMzk5MDA5NmQ0
MmVlZmVhOTE4OWUwNjVmYTVjNDI3MTNkZGM4MyAxMDA2NDQKLS0tIGEvVG9vbHMvU2NyaXB0cy93
ZWJraXRweS90b29sL2JvdC9jb21taXRxdWV1ZXRhc2tfdW5pdHRlc3QucHkKKysrIGIvVG9vbHMv
U2NyaXB0cy93ZWJraXRweS90b29sL2JvdC9jb21taXRxdWV1ZXRhc2tfdW5pdHRlc3QucHkKQEAg
LTYyMiwzICs2MjIsNCBAQCBjb21tYW5kX2ZhaWxlZDogZmFpbHVyZV9tZXNzYWdlPSdVbmFibGUg
dG8gbGFuZCBwYXRjaCcgc2NyaXB0X2Vycm9yPSdNT0NLIGxhbmQgZgogICAgICAgICBzZWxmLl9l
eHBlY3RfdmFsaWRhdGUoc2VsZi5fbW9ja19wYXRjaChidWdfZGljdD17J2J1Z19zdGF0dXMnOiAn
Q0xPU0VEJ30pLCBGYWxzZSkKICAgICAgICAgc2VsZi5fZXhwZWN0X3ZhbGlkYXRlKHNlbGYuX21v
Y2tfcGF0Y2goY29tbWl0dGVyPU5vbmUpLCBGYWxzZSkKICAgICAgICAgc2VsZi5fZXhwZWN0X3Zh
bGlkYXRlKHNlbGYuX21vY2tfcGF0Y2goeydyZXZpZXcnOiAnLSd9KSwgRmFsc2UpCisgICAgICAg
IHNlbGYuX2V4cGVjdF92YWxpZGF0ZShzZWxmLl9tb2NrX3BhdGNoKHsnY29tbWl0LXF1ZXVlJzog
Jy0nfSksIEZhbHNlKQo=
</data>

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>239414</attachid>
            <date>2014-10-07 10:03:03 -0700</date>
            <delta_ts>2014-10-07 14:05:03 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-137483-20141007190304.patch</filename>
            <type>text/plain</type>
            <size>2533</size>
            <attacher name="Csaba Osztrogonác">ossy</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMTc0MjMwCmRpZmYgLS1naXQgYS9Ub29scy9DaGFuZ2VMb2cg
Yi9Ub29scy9DaGFuZ2VMb2cKaW5kZXggYzAyMTU5MGFjZDE3ZWQzYzc0YWNjNDA4MDBlMDFhMTM1
NmJmZjU1ZC4uZWIxMzhkODNjZGZlZTYyZWJiYzBhMDc5NjUyNDRlOGQ2YTBlZDJjMSAxMDA2NDQK
LS0tIGEvVG9vbHMvQ2hhbmdlTG9nCisrKyBiL1Rvb2xzL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE1
IEBACisyMDE0LTEwLTA3ICBDc2FiYSBPc3p0cm9nb27DoWMgIDxvc3N5QHdlYmtpdC5vcmc+CisK
KyAgICAgICAgW3dlYmtpdHB5XSBDUS0gc2hvdWxkIG1lYW4gbm90IHZhbGlkIHBhdGNoIGZvciBj
b21taXQgcXVldWUKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dp
P2lkPTEzNzQ4MworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAg
ICAgICogU2NyaXB0cy93ZWJraXRweS90b29sL2JvdC9jb21taXRxdWV1ZXRhc2sucHk6CisgICAg
ICAgIChDb21taXRRdWV1ZVRhc2sudmFsaWRhdGUpOgorICAgICAgICAqIFNjcmlwdHMvd2Via2l0
cHkvdG9vbC9ib3QvY29tbWl0cXVldWV0YXNrX3VuaXR0ZXN0LnB5OgorICAgICAgICAodGVzdF92
YWxpZGF0ZSk6CisKIDIwMTQtMTAtMDIgIENvbW1pdCBRdWV1ZSAgPGNvbW1pdC1xdWV1ZUB3ZWJr
aXQub3JnPgogCiAgICAgICAgIFVucmV2aWV3ZWQsIHJvbGxpbmcgb3V0IHIxNzQxMjAuCmRpZmYg
LS1naXQgYS9Ub29scy9TY3JpcHRzL3dlYmtpdHB5L3Rvb2wvYm90L2NvbW1pdHF1ZXVldGFzay5w
eSBiL1Rvb2xzL1NjcmlwdHMvd2Via2l0cHkvdG9vbC9ib3QvY29tbWl0cXVldWV0YXNrLnB5Cmlu
ZGV4IGE5NWM3YjEwM2ExNWFlOGY3ZjI3OTZiMmRlZmZiNDNjMjRmZjc2OWYuLmJjNjZhYTFkNWNm
YmI0YzVhNjZkMWRiZWU4MmJmZWYwYTY1YTlmNWYgMTAwNjQ0Ci0tLSBhL1Rvb2xzL1NjcmlwdHMv
d2Via2l0cHkvdG9vbC9ib3QvY29tbWl0cXVldWV0YXNrLnB5CisrKyBiL1Rvb2xzL1NjcmlwdHMv
d2Via2l0cHkvdG9vbC9ib3QvY29tbWl0cXVldWV0YXNrLnB5CkBAIC01MCw2ICs1MCw4IEBAIGNs
YXNzIENvbW1pdFF1ZXVlVGFzayhQYXRjaEFuYWx5c2lzVGFzayk6CiAgICAgICAgICAgICByZXR1
cm4gRmFsc2UKICAgICAgICAgaWYgc2VsZi5fcGF0Y2gucmV2aWV3KCkgPT0gIi0iOgogICAgICAg
ICAgICAgcmV0dXJuIEZhbHNlCisgICAgICAgIGlmIHNlbGYuX3BhdGNoLmNvbW1pdF9xdWV1ZSgp
ICE9ICIrIjoKKyAgICAgICAgICAgIHJldHVybiBGYWxzZQogICAgICAgICByZXR1cm4gVHJ1ZQog
CiAgICAgZGVmIF92YWxpZGF0ZV9jaGFuZ2Vsb2coc2VsZik6CmRpZmYgLS1naXQgYS9Ub29scy9T
Y3JpcHRzL3dlYmtpdHB5L3Rvb2wvYm90L2NvbW1pdHF1ZXVldGFza191bml0dGVzdC5weSBiL1Rv
b2xzL1NjcmlwdHMvd2Via2l0cHkvdG9vbC9ib3QvY29tbWl0cXVldWV0YXNrX3VuaXR0ZXN0LnB5
CmluZGV4IGRjNGUzZDNlZjU4ODFlZDgzYzYxMzg3MGM3OGIzN2RhZmQ2ODgyNzcuLjBhMTNmYTk0
YWMwNzllYzNlYmE5ZjdkMzI0NTJjMGQ5MTY0ZWIzYzEgMTAwNjQ0Ci0tLSBhL1Rvb2xzL1Njcmlw
dHMvd2Via2l0cHkvdG9vbC9ib3QvY29tbWl0cXVldWV0YXNrX3VuaXR0ZXN0LnB5CisrKyBiL1Rv
b2xzL1NjcmlwdHMvd2Via2l0cHkvdG9vbC9ib3QvY29tbWl0cXVldWV0YXNrX3VuaXR0ZXN0LnB5
CkBAIC02MTcsOCArNjE3LDExIEBAIGNvbW1hbmRfZmFpbGVkOiBmYWlsdXJlX21lc3NhZ2U9J1Vu
YWJsZSB0byBsYW5kIHBhdGNoJyBzY3JpcHRfZXJyb3I9J01PQ0sgbGFuZCBmCiAgICAgICAgIHJl
dHVybiBwYXRjaAogCiAgICAgZGVmIHRlc3RfdmFsaWRhdGUoc2VsZik6Ci0gICAgICAgIHNlbGYu
X2V4cGVjdF92YWxpZGF0ZShzZWxmLl9tb2NrX3BhdGNoKCksIFRydWUpCisgICAgICAgIHNlbGYu
X2V4cGVjdF92YWxpZGF0ZShzZWxmLl9tb2NrX3BhdGNoKCksIEZhbHNlKQogICAgICAgICBzZWxm
Ll9leHBlY3RfdmFsaWRhdGUoc2VsZi5fbW9ja19wYXRjaCh7J2lzX29ic29sZXRlJzogVHJ1ZX0p
LCBGYWxzZSkKICAgICAgICAgc2VsZi5fZXhwZWN0X3ZhbGlkYXRlKHNlbGYuX21vY2tfcGF0Y2go
YnVnX2RpY3Q9eydidWdfc3RhdHVzJzogJ0NMT1NFRCd9KSwgRmFsc2UpCiAgICAgICAgIHNlbGYu
X2V4cGVjdF92YWxpZGF0ZShzZWxmLl9tb2NrX3BhdGNoKGNvbW1pdHRlcj1Ob25lKSwgRmFsc2Up
CiAgICAgICAgIHNlbGYuX2V4cGVjdF92YWxpZGF0ZShzZWxmLl9tb2NrX3BhdGNoKHsncmV2aWV3
JzogJy0nfSksIEZhbHNlKQorICAgICAgICBzZWxmLl9leHBlY3RfdmFsaWRhdGUoc2VsZi5fbW9j
a19wYXRjaCh7J2NvbW1pdC1xdWV1ZSc6ICctJ30pLCBGYWxzZSkKKyAgICAgICAgc2VsZi5fZXhw
ZWN0X3ZhbGlkYXRlKHNlbGYuX21vY2tfcGF0Y2goeydjb21taXQtcXVldWUnOiAnPyd9KSwgRmFs
c2UpCisgICAgICAgIHNlbGYuX2V4cGVjdF92YWxpZGF0ZShzZWxmLl9tb2NrX3BhdGNoKHsnY29t
bWl0LXF1ZXVlJzogJysnfSksIFRydWUpCg==
</data>

          </attachment>
      

    </bug>

</bugzilla>