1:11 a.m.
----_com.android.email_1462209507407830
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
T24gdGhlIG90aGVyIGhhbmQsIGNoYW5naW5nIGEgamFyIGluIHRoZSBydW50aW1lIGVudmlyb25t
ZW50IHdpdGhvdXQgY29tcGlsaW5nIGFuZCBydW5uaW5nIHRlc3Qgd2l0aCB0aGUgbmV3IGphciBj
b3VsZCBsZWFkIGFuIGFwcGxpY2F0aW9uIHRvIHN0b3AgZnVuY3Rpb25pbmcgaW4gYSBjdXN0b21l
ciBlbnZpcm9ubWVudC4KQWxzbyBub3QgZXZlcnkgYnVnIGZvdW5kIGluIGEgZGVwZW5kZW5jeSBq
YXIgd291bGQgY2F1c2UgYSBwcm9ibGVtIGluIHRoZSBhcHBsaWNhdGlvbi4gKEFuIGFwcGxpY2F0
aW9uIG1pZ2h0IG5vdCB1c2UgdGhlIHByb2JsZW1hdGljIHBhcnQgb2YgdGhlIGRlcGVuZGVuY3ku
KQpJJ2QgYmV0dGVyIHRydXN0IHRoZSB0ZXN0IHN1aXRlIChhdXRvbWF0aWMgYW5kIG1hbnVhbCkg
dGhhdCB3ZSBydW4gb24gdGhlIGNvbXBpbGVkIGFwcGxpY2F0aW9uIHdpdGggYWxsIHRoZSBkZXBl
bmRlbmNpZXMgdGhhdCB0aGUgZGV2ZWxvcGVycyBjaG9vc2UgYXQgdGhlIGRldmVsb3BtZW50IHRp
bWUgYW5kIHRoZW4gZGVsaXZlciB0aGF0ICh3aXRoIGl0cyBkZXBlbmRlbmNpZXMgYXMgYSBzaW5n
bGUgcGFja2FnZSkgdG8gdGhlIGN1c3RvbWVycy4KRXZlcnkgYnVnIGluIGEgZGVwZW5kZW5jeSBz
aG91bGQgYmUgZXZhbHVhdGVkIHdpdGhpbiB0aGUgZ2l2ZW4gYXBwbGljYXRpb24gc2NvcGUgYW5k
IG9ubHkgaWYgcHJvdmVuIGFzIHRoZSBnaXZlbiBhcHBsaWNhdGlvbiBwcm9ibGVtIG9ubHkgdGhl
biB0aGUgYXBwbGljYXRpb24gc2hvdWxkIGJlIHJlbGVhc2VkLgoKClNlbnQgZnJvbSBTYW1zdW5n
IE1vYmlsZQoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBBbG9uIEJh
ci1MZXYgPGFsb25ibEByZWRoYXQuY29tPiAKRGF0ZTogMDcvMDUvMjAxNCAgMjE6NDEgIChHTVQr
MDI6MDApIApUbzogTWlrZSBLb2xlc25payA8bWtvbGVzbmlAcmVkaGF0LmNvbT4gCkNjOiBZZXZn
ZW55IFphc3BpdHNreSA8eXphc3BpdHNAcmVkaGF0LmNvbT4sZGV2ZWxAb3ZpcnQub3JnIApTdWJq
ZWN0OiBSZTogW292aXJ0LWRldmVsXSBjb21tb25zLWNvbGxlY3Rpb25zIHY0LjAgCiAKCgotLS0t
LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogIk1pa2UgS29sZXNuaWsiIDxta29sZXNu
aUByZWRoYXQuY29tPgo+IFRvOiAiQWxvbiBCYXItTGV2IiA8YWxvbmJsQHJlZGhhdC5jb20+Cj4g
Q2M6ICJZZXZnZW55IFphc3BpdHNreSIgPHl6YXNwaXRzQHJlZGhhdC5jb20+LCBkZXZlbEBvdmly
dC5vcmcKPiBTZW50OiBXZWRuZXNkYXksIE1heSA3LCAyMDE0IDk6MzQ6MDMgUE0KPiBTdWJqZWN0
OiBSZTogW292aXJ0LWRldmVsXSBjb21tb25zLWNvbGxlY3Rpb25zIHY0LjAKPiAKPiAtLS0tLSBP
cmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gPiAKPiA+IAo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2Fn
ZSAtLS0tLQo+ID4gPiBGcm9tOiAiWWV2Z2VueSBaYXNwaXRza3kiIDx5emFzcGl0c0ByZWRoYXQu
Y29tPgo+ID4gPiBUbzogIkFsb24gQmFyLUxldiIgPGFsb25ibEByZWRoYXQuY29tPgo+ID4gPiBD
YzogZGV2ZWxAb3ZpcnQub3JnCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDIyLCAyMDE0IDEx
OjM5OjExIEFNCj4gPiA+IFN1YmplY3Q6IFJlOiBbb3ZpcnQtZGV2ZWxdIGNvbW1vbnMtY29sbGVj
dGlvbnMgdjQuMAo+ID4gPiAKPiA+ID4gVGhhdCBtZWFucyB0aGF0IHdlIG1hbmFnZSAyIHNlcGFy
YXRlIGVudmlyb25tZW50czoKPiA+ID4gMS4gRGV2ZWxvcG1lbnQgLSByZWxpZXMgb24gcG9tIGZp
bGVzLiBFLmcuIHVuaXQgdGVzdHMgcnVuIHdpdGgKPiA+ID4gY29tbW9ucy1jb2xsZWN0aW9ucyB2
My4xIChhbmQgd2hlbiBJIGFkZCB2NC4wKSBhbmQgc3VjY2VlZC4KPiA+IAo+ID4gZGV2ZW52IHdp
bGwgdXNlIHJ1bnRpbWUgb3B0aW9uLgo+ID4geW91IGFyZSByaWdodCBhYm91dCB0aGUgdW5pdCB0
ZXN0cywgdGhlc2UgcmVsYXlzIG9uIHRoZSBwb21zLgo+IAo+IEkgdXNlIGRldmVudiBhbmQgaXQg
YWx3YXlzIHVzZXMgdGhlIGRldiBvcHRpb24gbm90IHRoZSBydW50aW1lLgo+IFNvIGJhc2ljYWxs
eSBkZXZlbG9wZXJzIGFyZSB1c2luZyB0aGUgcG9tIHNwZWNpZmllZCB2ZXJzaW9ucyBhbmQgbm90
IHdoYXQKPiB1c2VkIGluIHJ1bnRpbWUuCj4gCj4gRXZlbiBtb3JlIHNvLCBpbiBydW50aW1lIGl0
IGhpZ2hseSBkZXBlbmRzIG9uIHdoYXQgT1MgeW91J3JlIHVzaW5nLCBzbwo+IHNvbWVvbmUKPiBk
ZXZlbG9waW5nIG9uIEYxOSBtaWdodCBub3QgYmUgdXNpbmcgc2FtZSB2ZXJzaW9ucyBhcyBhIGRl
dmVsb3BlciBvbiBGMjAgYW5kCj4gYm90aCBhcmUgcHJvYmFibHkgdmVyeSBkaWZmZXJlbnQgdmVy
c2lvbnMgdGhhbiBvbiBSSEVML0NlbnRPUy4KPiBJIHdvbid0IGV2ZW4gbWVudGlvbiBvdGhlciBP
U2BzLgo+IAo+ID4gCj4gPiA+IDIuIFJ1bi10aW1lIC0gcmVsaWVzIG9uIEpCb3NzIG93biBkZXBl
bmRlbmNpZXMgdGhhdCBicmluZwo+ID4gPiBjb21tb25zLWNvbGxlY3Rpb24KPiA+ID4gdjMuMi4x
LXJlZGhhdC0yLgo+ID4gCj4gPiBpbiByaGVsIGNhc2UsIHllcy4KPiA+IAo+ID4gPiBUaGlzIGtp
bmQgb2YgZGlzY3JlcGFuY2llcyBtaWdodCBiZSBmb3VuZCBpbiBvdGhlciBsaWJyYXJpZXMgYXMg
d2UgZG8gbm90Cj4gPiA+IHN5bmNocm9uaXplIG91ciBwb20gZmlsZXMgd2l0aCB0aGUgSkJvc3Mg
Y3VycmVudCB2ZXJzaW9uIGRlcGVuZGVuY2llcy4KPiA+ID4gSU1ITyB0aGF0IGNvdWxkIGxlYWQg
dG8gc29tZSB2ZXJ5IGRpZmZpY3VsdCBidWdzIHRoYXQgd2Ugd29uJ3QgYmUgYWJsZSB0bwo+ID4g
PiBzaW11bGF0ZSBpbiBvdXIgdW5pdCB0ZXN0cy4KPiA+IAo+ID4gY29ycmVjdCwgYnV0IHRoZSBq
YXZhIHdheSB0byBwdWxsIGRlcGVuZGVuY2llcyBhdCB3aWxsIHdpdGhvdXQgYmVpbmcgYWJsZQo+
ID4gdG8KPiA+IGZpeCB6LXN0cmVhbSB1c2luZyBjZW50cmFsIHBhY2thZ2UgbWFuYWdlbWVudCB0
b29scyBpcyBtb3JlIHNldmVyZSB0aGFuCj4gPiB1bml0Cj4gPiB0ZXN0cyBub3Qgd29ya2luZy9u
b3Qgd29ya2luZy4KPiA+IAo+ID4gZm9yIGV4YW1wbGUsIHlvdXIgYXBwbGljYXRpb24gdXNlcyB4
LmphciBhbmQgYWN0dWFsbHkgZGVsaXZlcnMgeC5qYXIuLi4gc28KPiA+IGZyb20gcmVsZWFzZSB0
byBldGVybml0eSBpdCBpcyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIHRyYWNrIHguamFyIGZvcgo+
ID4gc2V2ZXJlCj4gPiBzdGFiaWxpdHkgYnVncyBhbmQgc2VjdXJpdHkgYnVncywgYW5kIHJlbGVh
c2UgeW91ciBlbnRpcmUgYXBwbGljYXRpb24gZWFjaAo+ID4gdGltZSBmb3VuZCwgbm93IG11bHRp
cGxlIGl0IHdpdGggdGhlICMgb2YgY29tcG9uZW50cyBhcHBsaWNhdGlvbiBpcyB1c2luZwo+ID4g
YW5kIHNlZSBob3cgbXVjaCBlZmZvcnQgeW91IGhhdmUganVzdCB0byBtYWludGFpbiBzdGFiaWxp
dHkgYW5kIHNlY3VyaXR5IGlmCj4gPiB5b3UgZW1iZWQgM3JkIHBhcnR5IGNvbXBvbmVudHMgd2l0
aG91dCB5b3VyIGFwcGxpY2F0aW9uLgo+IAo+IFllcywgaWYgeW91IHVzZSBwYWNrYWdlIFggdGhl
biB5b3UncmUgdXNpbmcgdGhhdCBzcGVjaWZpYyB2ZXJzaW9uIHdpdGggaXQncwo+IGJlaGF2aW91
ciBhbmQgQVBJLCB0aGlzIGlzIHdoeSBkZXBlbmRlbmNpZXMgYXJlbid0IHVwZGF0ZWQgbGlnaHQg
aGVhZGVkbHkgYnV0Cj4gd2l0aCB0ZXN0aW5nIHRvIHNlZSB0aGF0IG5vdGhpbmcgYnJva2UgKHNp
bmNlIHN0dWZmIGRvZXMgYnJlYWssIGV2ZW4gaW4gbWlub3IKPiB2ZXJzaW9uLCBhcyB3ZSBsZWF2
ZSBpbiBhIG5vdCBzbyBwZXJmZWN0IHdvcmxkKS4KPiAKPiA+IAo+ID4gPiBXaHkgZG8gd2UgYXZv
aWQgInRvIG1haW50YWluIG91ciBvd24gcGFja2FnaW5nIj8gSU1ITyBPdmlydCBvd24KPiA+ID4g
ZGVwZW5kZW5jaWVzCj4gPiA+IGNvdWxkIGJlIHBhY2tlZCBpbiB0aGUgd2FyLCBjYW4ndCB0aGV5
Pwo+ID4gCj4gPiB5ZXMgdGhleSBjb3VsZCwgYnV0IHRoaXMgaXMgbm90IHN1aXRhYmxlIGZvciBl
bnRlcnByaXNlIGdyYWRlCj4gPiBpbXBsZW1lbnRhdGlvbnMsIG1haW5seSBwZXIgd2hhdCBJIGRl
c2NyaWJlZCBhYm92ZS4KPiAKPiBTb3JyeSBidXQgQUZBSUsgZW50ZXJwcmlzZSBncmFkZSBzb2Z0
d2FyZSByZWxlYXNlIGZpeGVzIGZvciB0aGVpciBzb2Z0d2FyZQo+IG9uIGEgdGltZWx5IGJhc2lz
IGFuZCBoYXZlIHByb2Nlc3NlcyBpbiBwbGFjZSB0byBtYW5hZ2UgdXBncmFkZXMgb2YKPiBmdW5j
dGlvbmFsaXR5Lgo+IAo+IFdoYXQgY3VycmVudGx5IGlzIGRvbmUgaXMgcmVseWluZyBvbiBjb3Vy
dGVzeSBvZiBvdGhlciBwZW9wbGUgdG8gcmVsZWFzZSBhCj4gImZpeCIgdGhhdCBhbHJlYWR5IGV4
aXN0cyBhIGxvbmcgdGltZS4KPiBBbmQgb2YgY291cnNlLCBhcyBJIG1lbnRpb25lZCwgdGhlIGFw
cGxpY2F0aW9uIG5lZWRzIHRvIGJlIHRlc3RlZCB3aXRoIHRoZQo+IHVwZGF0ZWQgbGlicmFyeS4K
PiBJTU8gbmVnbGVjdGluZyB0aGlzIGFuZCBsZWF2aW5nIHRoaXMgb3V0IG9mIGJhbmQgZm9yICJl
bnRlcnByaXNlIGdyYWRlIgo+IHNvZnR3YXJlIGlzIG11Y2ggd29yc2UgdGhhbiBhY3R1YWxseSB0
ZXN0aW5nIHRvIHNlZSB0aGF0IGl0IGlzIHdvcmtpbmcgYW5kCj4ganVzdCBsZWF2aW5nIGl0IGFs
bCB0byBjaGFuY2UuCgrigI5XZWxsLCB0YWtlIHRoZSByZWNlbnQgZXhhbXBsZSBvZiBvcGVuc3Ns
IGlzc3VlIHRoYXQgd2FzIGZvdW5kLgpOb3csIGltYWdpbmUgdGhhdCBhbGwgcHJvZHVjdHMgdGhh
dCB1c2Ugb3BlbnNzbCBzaG91bGQgaGF2ZSBiZWVuIHJlLXJlbGVhc2VkLgpJIHRoaW5rIHRoaXMg
aXMgZW5vdWdoIHRvIHVuZGVyc3RhbmQgaG93IHdyb25nIHRoaXMgaXMuCgo+IAo+ID4gCj4gPiBS
ZWdhcmRzLAo+ID4gQWxvbgo+ID4gCj4gPiA+IEJlc3QgcmVnYXJkcywKPiA+ID4gX19fX19fX19f
X19fX19fX19fX18KPiA+ID4gWWV2Z2VueSBaYXNwaXRza3kKPiA+ID4gU2VuaW9yIFNvZnR3YXJl
IEVuZ2luZWVyCj4gPiA+IFJlZCBIYXQgSXNyYWVsCj4gPiA+IAo+ID4gPiAKPiA+ID4gLS0tLS0g
T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+ID4gPiBGcm9tOiAiQWxvbiBCYXItTGV2IiA8YWxvbmJs
QHJlZGhhdC5jb20+Cj4gPiA+IFRvOiAiWWV2Z2VueSBaYXNwaXRza3kiIDx5emFzcGl0c0ByZWRo
YXQuY29tPgo+ID4gPiBDYzogZGV2ZWxAb3ZpcnQub3JnCj4gPiA+IFNlbnQ6IFN1bmRheSwgQXBy
aWwgMTMsIDIwMTQgNzoyMjoxOCBQTQo+ID4gPiBTdWJqZWN0OiBSZTogW292aXJ0LWRldmVsXSBj
b21tb25zLWNvbGxlY3Rpb25zIHY0LjAKPiA+ID4gCj4gPiA+IAo+ID4gPiAKPiA+ID4gLS0tLS0g
T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+ID4gPiA+IEZyb206ICJZZXZnZW55IFphc3BpdHNreSIg
PHl6YXNwaXRzQHJlZGhhdC5jb20+Cj4gPiA+ID4gVG86IGRldmVsQG92aXJ0Lm9yZwo+ID4gPiA+
IFNlbnQ6IFN1bmRheSwgQXByaWwgMTMsIDIwMTQgNzoxMzoxMCBQTQo+ID4gPiA+IFN1YmplY3Q6
IFtvdmlydC1kZXZlbF0gY29tbW9ucy1jb2xsZWN0aW9ucyB2NC4wCj4gPiA+ID4gCj4gPiA+ID4g
SGkgQWxsLAo+ID4gPiA+IAo+ID4gPiA+IEknZCBsaWtlIHRvIGFkZCB0aGUgbmV3IHZlcnNpb24g
KDQuMCkgb2YgQXBhY2hlIGNvbW1vbnMtY29sbGVjdGlvbnMKPiA+ID4gPiBsaWJyYXJ5Cj4gPiA+
ID4gdG8gdGhlIGRlcGVuZGVuY2llcyBvZiB0aGUgcHJvamVjdCAod2UgdXNlIDMuMSBjdXJyZW50
bHkpLgo+ID4gPiA+IFRoZSBuZXcgdmVyc2lvbiB1c2VzIHRoZSBnZW5lcmljcyBmZWF0dXJlcyBv
ZiBKYXZhIDUgc28gdGhhdCBtYWtlIHRoZQo+ID4gPiA+IGNvZGUKPiA+ID4gPiBtb3JlIHR5cGUg
c2FmZS4gWW91IGNhbiBmaW5kIHRoZSBmdWxsIGxpc3Qgb2YgY2hhbmdlcyBvbgo+ID4gPiA+IGh0
dHBzOi8vY29tbW9ucy5hcGFjaGUub3JnL3Byb3Blci9jb21tb25zLWNvbGxlY3Rpb25zL3JlbGVh
c2VfNF8wLmh0bWwuCj4gPiA+ID4gVGhlIG5ldyBBUEkgaXMgYmFzZWQgb24gdGhlIG9yaWdpbmFs
IGJ1dCBpdCBpc24ndCBmdWxseSBjb21wYXRpYmxlIHdpdGgKPiA+ID4gPiBpdC4KPiA+ID4gPiBT
byBpbiBvcmRlciB0byBtYWtlIHRoZSBtaWdyYXRpb24gdG8gdGhlIG5ldyBBUEkgZWFzaWVyLCB0
aGUgcGFja2FnZQo+ID4gPiA+IGhhcwo+ID4gPiA+IGJlZW4gY2hhbmdlZCB0byBvcmcuYXBhY2hl
LmNvbW1vbnMuY29sbGVjdGlvbnM0LiBUaGF0IGFsbG93cyBoYXZpbmcKPiA+ID4gPiBib3RoCj4g
PiA+ID4gdmVyc2lvbiBvZiB0aGUgbGlicmFyeSBpbiB0aGUgY2xhc3NwYXRoIGF0IHRoZSBzdGFy
dGluZyBwb2ludCBhbmQgbW92ZQo+ID4gPiA+IChyZWZhY3RvcikgdG93YXJkcyB0aGUgbmV3IHZl
cnNpb24gZ3JhZHVhbGx5Lgo+ID4gPiA+IAo+ID4gPiA+IEkgaGF2ZSBjb3VwbGUgb2YgcXVlc3Rp
b25zIHJlZ2FyZGluZyB0aGUgbmV3IGRlcGVuZGVuY3k6Cj4gPiA+ID4gMS4gSXMgdGhlcmUgYW55
dGhpbmcgdGhhdCBjb3VsZCBwcmV2ZW50IGFkZGluZyB0aGUgbmV3IGRlcGVuZGVuY3k/Cj4gPiA+
IAo+ID4gPiBXZSB0cnkgdG8gYXZvaWQgaW50cm9kdWNpbmcgb3VyIG93biBkZXBlbmRlbmNpZXMs
IGluIHRoaXMgY2FzZSB3ZSB1c2UKPiA+ID4gd2hhdGV2ZXIgamJvc3MgcHJvdmlkZXMgd2hpY2gg
aXMgdmVyeSBjb21mb3J0YWJsZSBhcyB3ZSBkbyBub3QgbmVlZCB0bwo+ID4gPiBtYWludGFpbiBv
dXIgb3duIHBhY2thZ2luZy4KPiA+ID4gCj4gPiA+IEN1cnJlbnRseSB0aGUgamJlYXAgZG9lcyBu
b3QgcHJvdmlkZSA0LjAsIGl0IGRvZXMgc3VwcG9ydCAzLjIuMS1yZWRoYXQtMiwKPiA+ID4gc28K
PiA+ID4gYmV0dGVyIHRvIGF2b2lkIHRoaXMgdW50aWwgd2Ugc3dpdGNoIHRvIG1vcmUgcmVjZW50
IHZlcnNpb24gb2YgamJvc3MuCj4gPiA+IAo+ID4gPiBBbHRlcm5hdGl2ZWx5IHdlIGNvdWxkIGVu
am95IHN0YW5kYWxvbmUgcnBtIHdpdGhpbiByaGVsL2NlbnRvcyBpZgo+ID4gPiBhdmFpbGFibGUs
Cj4gPiA+IGhvd2V2ZXIgbm9uIGV4aXN0Lgo+ID4gPiAKPiA+ID4gPiAyLiBJIGRpZCB0aGUgY2hh
bmdlIChodHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8yNjc0NSkuCj4gPiA+ID7CoMKgwqAgVGhlIHVu
aXQgdGVzdHMgdGhhdCB1c2UgdGhlIG5ldyBkZXBlbmRlbmN5IHBhc3MgbG9jYWxseSBhbmQgaW4K
PiA+ID4gPsKgwqDCoCBKZW5raW5zCj4gPiA+ID7CoMKgwqAgZW52aXJvbm1lbnRzLgo+ID4gPiA+
wqDCoMKgIEhvd2V2ZXIgd2hlbiBJIHRyeSB0byBydW4gYSBjb2RlIHRoYXQgaXMgZGVwZW5kZW50
IG9uIHRoZSBuZXdseQo+ID4gPiA+wqDCoMKgIGFkZGVkCj4gPiA+ID7CoMKgwqAgbGlicmFyeSBO
b0NsYXNzRGVmRm91bmRFcnJvciBiZWluZyB0aHJvd24uCj4gPiA+ID7CoMKgwqAgQWxzbyBJIGNh
bid0IGZpbmQgY29tbW9ucy1jb2xsZWN0aW9uczQgamFyIHVuZGVyIHRoZSBpbnN0YWxsYXRpb24K
PiA+ID4gPsKgwqDCoCBkaXJlY3RvcnkuIEkgdXNlICJtYWtlIGNsZWFuIGluc3RhbGwtZGV2IiBj
b21tYW5kIGZvciBidWlsZGluZy4KPiA+ID4gPiAKPiA+ID4gPiBQbGVhc2UgYWR2aXNlLgo+ID4g
Cj4gCg==
----_com.android.email_1462209507407830
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5PbiB0aGUgb3RoZXIgaGFu
ZCwgY2hhbmdpbmcgYSBqYXIgaW4gdGhlIHJ1bnRpbWUgZW52aXJvbm1lbnQgd2l0aG91dCBjb21w
aWxpbmcgYW5kIHJ1bm5pbmcgdGVzdCB3aXRoIHRoZSBuZXcgamFyIGNvdWxkIGxlYWQgYW4gYXBw
bGljYXRpb24gdG8gc3RvcCBmdW5jdGlvbmluZyBpbiBhIGN1c3RvbWVyIGVudmlyb25tZW50Ljwv
ZGl2PjxkaXY+QWxzbyBub3QgZXZlcnkgYnVnIGZvdW5kIGluIGEgZGVwZW5kZW5jeSBqYXIgd291
bGQgY2F1c2UgYSBwcm9ibGVtIGluIHRoZSBhcHBsaWNhdGlvbi4gKEFuIGFwcGxpY2F0aW9uIG1p
Z2h0IG5vdCB1c2UgdGhlIHByb2JsZW1hdGljIHBhcnQgb2YgdGhlIGRlcGVuZGVuY3kuKTwvZGl2
PjxkaXY+SSdkIGJldHRlciB0cnVzdCB0aGUgdGVzdCBzdWl0ZSAoYXV0b21hdGljIGFuZCBtYW51
YWwpIHRoYXQgd2UgcnVuIG9uIHRoZSBjb21waWxlZCBhcHBsaWNhdGlvbiB3aXRoIGFsbCB0aGUg
ZGVwZW5kZW5jaWVzIHRoYXQgdGhlIGRldmVsb3BlcnMgY2hvb3NlIGF0IHRoZSBkZXZlbG9wbWVu
dCB0aW1lIGFuZCB0aGVuIGRlbGl2ZXIgdGhhdCAod2l0aCBpdHMgZGVwZW5kZW5jaWVzIGFzIGEg
c2luZ2xlIHBhY2thZ2UpIHRvIHRoZSBjdXN0b21lcnMuPC9kaXY+PGRpdj5FdmVyeSBidWcgaW4g
YSBkZXBlbmRlbmN5IHNob3VsZCBiZSBldmFsdWF0ZWQgd2l0aGluIHRoZSBnaXZlbiBhcHBsaWNh
dGlvbiBzY29wZSBhbmQgb25seSBpZiBwcm92ZW4gYXMgdGhlIGdpdmVuIGFwcGxpY2F0aW9uIHBy
b2JsZW0gb25seSB0aGVuIHRoZSBhcHBsaWNhdGlvbiBzaG91bGQgYmUgcmVsZWFzZWQuPC9kaXY+
PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6
NzUlO2NvbG9yOiM1NzU3NTciPlNlbnQgZnJvbSBTYW1zdW5nIE1vYmlsZTwvZGl2PjwvZGl2Pjxi
cj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJvbTogQWxv
biBCYXItTGV2ICZsdDthbG9uYmxAcmVkaGF0LmNvbSZndDsgPGJyPkRhdGU6IDA3LzA1LzIwMTQg
IDIxOjQxICAoR01UKzAyOjAwKSA8YnI+VG86IE1pa2UgS29sZXNuaWsgJmx0O21rb2xlc25pQHJl
ZGhhdC5jb20mZ3Q7IDxicj5DYzogWWV2Z2VueSBaYXNwaXRza3kgJmx0O3l6YXNwaXRzQHJlZGhh
dC5jb20mZ3Q7LGRldmVsQG92aXJ0Lm9yZyA8YnI+U3ViamVjdDogUmU6IFtvdmlydC1kZXZlbF0g
Y29tbW9ucy1jb2xsZWN0aW9ucyB2NC4wIDxicj4gPGJyPjxicj48YnI+PGJyPi0tLS0tIE9yaWdp
bmFsIE1lc3NhZ2UgLS0tLS08YnI+Jmd0OyBGcm9tOiAiTWlrZSBLb2xlc25payIgJmx0O21rb2xl
c25pQHJlZGhhdC5jb20mZ3Q7PGJyPiZndDsgVG86ICJBbG9uIEJhci1MZXYiICZsdDthbG9uYmxA
cmVkaGF0LmNvbSZndDs8YnI+Jmd0OyBDYzogIllldmdlbnkgWmFzcGl0c2t5IiAmbHQ7eXphc3Bp
dHNAcmVkaGF0LmNvbSZndDssIGRldmVsQG92aXJ0Lm9yZzxicj4mZ3Q7IFNlbnQ6IFdlZG5lc2Rh
eSwgTWF5IDcsIDIwMTQgOTozNDowMyBQTTxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbb3ZpcnQtZGV2
ZWxdIGNvbW1vbnMtY29sbGVjdGlvbnMgdjQuMDxicj4mZ3Q7IDxicj4mZ3Q7IC0tLS0tIE9yaWdp
bmFsIE1lc3NhZ2UgLS0tLS08YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0
OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPiZndDsgJmd0OyAmZ3Q7IEZyb206ICJZ
ZXZnZW55IFphc3BpdHNreSIgJmx0O3l6YXNwaXRzQHJlZGhhdC5jb20mZ3Q7PGJyPiZndDsgJmd0
OyAmZ3Q7IFRvOiAiQWxvbiBCYXItTGV2IiAmbHQ7YWxvbmJsQHJlZGhhdC5jb20mZ3Q7PGJyPiZn
dDsgJmd0OyAmZ3Q7IENjOiBkZXZlbEBvdmlydC5vcmc8YnI+Jmd0OyAmZ3Q7ICZndDsgU2VudDog
VHVlc2RheSwgQXByaWwgMjIsIDIwMTQgMTE6Mzk6MTEgQU08YnI+Jmd0OyAmZ3Q7ICZndDsgU3Vi
amVjdDogUmU6IFtvdmlydC1kZXZlbF0gY29tbW9ucy1jb2xsZWN0aW9ucyB2NC4wPGJyPiZndDsg
Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyBUaGF0IG1lYW5zIHRoYXQgd2UgbWFuYWdlIDIg
c2VwYXJhdGUgZW52aXJvbm1lbnRzOjxicj4mZ3Q7ICZndDsgJmd0OyAxLiBEZXZlbG9wbWVudCAt
IHJlbGllcyBvbiBwb20gZmlsZXMuIEUuZy4gdW5pdCB0ZXN0cyBydW4gd2l0aDxicj4mZ3Q7ICZn
dDsgJmd0OyBjb21tb25zLWNvbGxlY3Rpb25zIHYzLjEgKGFuZCB3aGVuIEkgYWRkIHY0LjApIGFu
ZCBzdWNjZWVkLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBkZXZlbnYgd2lsbCB1c2UgcnVu
dGltZSBvcHRpb24uPGJyPiZndDsgJmd0OyB5b3UgYXJlIHJpZ2h0IGFib3V0IHRoZSB1bml0IHRl
c3RzLCB0aGVzZSByZWxheXMgb24gdGhlIHBvbXMuPGJyPiZndDsgPGJyPiZndDsgSSB1c2UgZGV2
ZW52IGFuZCBpdCBhbHdheXMgdXNlcyB0aGUgZGV2IG9wdGlvbiBub3QgdGhlIHJ1bnRpbWUuPGJy
PiZndDsgU28gYmFzaWNhbGx5IGRldmVsb3BlcnMgYXJlIHVzaW5nIHRoZSBwb20gc3BlY2lmaWVk
IHZlcnNpb25zIGFuZCBub3Qgd2hhdDxicj4mZ3Q7IHVzZWQgaW4gcnVudGltZS48YnI+Jmd0OyA8
YnI+Jmd0OyBFdmVuIG1vcmUgc28sIGluIHJ1bnRpbWUgaXQgaGlnaGx5IGRlcGVuZHMgb24gd2hh
dCBPUyB5b3UncmUgdXNpbmcsIHNvPGJyPiZndDsgc29tZW9uZTxicj4mZ3Q7IGRldmVsb3Bpbmcg
b24gRjE5IG1pZ2h0IG5vdCBiZSB1c2luZyBzYW1lIHZlcnNpb25zIGFzIGEgZGV2ZWxvcGVyIG9u
IEYyMCBhbmQ8YnI+Jmd0OyBib3RoIGFyZSBwcm9iYWJseSB2ZXJ5IGRpZmZlcmVudCB2ZXJzaW9u
cyB0aGFuIG9uIFJIRUwvQ2VudE9TLjxicj4mZ3Q7IEkgd29uJ3QgZXZlbiBtZW50aW9uIG90aGVy
IE9TYHMuPGJyPiZndDsgPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgMi4gUnVuLXRp
bWUgLSByZWxpZXMgb24gSkJvc3Mgb3duIGRlcGVuZGVuY2llcyB0aGF0IGJyaW5nPGJyPiZndDsg
Jmd0OyAmZ3Q7IGNvbW1vbnMtY29sbGVjdGlvbjxicj4mZ3Q7ICZndDsgJmd0OyB2My4yLjEtcmVk
aGF0LTIuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IGluIHJoZWwgY2FzZSwgeWVzLjxicj4m
Z3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IFRoaXMga2luZCBvZiBkaXNjcmVwYW5jaWVzIG1p
Z2h0IGJlIGZvdW5kIGluIG90aGVyIGxpYnJhcmllcyBhcyB3ZSBkbyBub3Q8YnI+Jmd0OyAmZ3Q7
ICZndDsgc3luY2hyb25pemUgb3VyIHBvbSBmaWxlcyB3aXRoIHRoZSBKQm9zcyBjdXJyZW50IHZl
cnNpb24gZGVwZW5kZW5jaWVzLjxicj4mZ3Q7ICZndDsgJmd0OyBJTUhPIHRoYXQgY291bGQgbGVh
ZCB0byBzb21lIHZlcnkgZGlmZmljdWx0IGJ1Z3MgdGhhdCB3ZSB3b24ndCBiZSBhYmxlIHRvPGJy
PiZndDsgJmd0OyAmZ3Q7IHNpbXVsYXRlIGluIG91ciB1bml0IHRlc3RzLjxicj4mZ3Q7ICZndDsg
PGJyPiZndDsgJmd0OyBjb3JyZWN0LCBidXQgdGhlIGphdmEgd2F5IHRvIHB1bGwgZGVwZW5kZW5j
aWVzIGF0IHdpbGwgd2l0aG91dCBiZWluZyBhYmxlPGJyPiZndDsgJmd0OyB0bzxicj4mZ3Q7ICZn
dDsgZml4IHotc3RyZWFtIHVzaW5nIGNlbnRyYWwgcGFja2FnZSBtYW5hZ2VtZW50IHRvb2xzIGlz
IG1vcmUgc2V2ZXJlIHRoYW48YnI+Jmd0OyAmZ3Q7IHVuaXQ8YnI+Jmd0OyAmZ3Q7IHRlc3RzIG5v
dCB3b3JraW5nL25vdCB3b3JraW5nLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBmb3IgZXhh
bXBsZSwgeW91ciBhcHBsaWNhdGlvbiB1c2VzIHguamFyIGFuZCBhY3R1YWxseSBkZWxpdmVycyB4
Lmphci4uLiBzbzxicj4mZ3Q7ICZndDsgZnJvbSByZWxlYXNlIHRvIGV0ZXJuaXR5IGl0IGlzIHlv
dXIgcmVzcG9uc2liaWxpdHkgdG8gdHJhY2sgeC5qYXIgZm9yPGJyPiZndDsgJmd0OyBzZXZlcmU8
YnI+Jmd0OyAmZ3Q7IHN0YWJpbGl0eSBidWdzIGFuZCBzZWN1cml0eSBidWdzLCBhbmQgcmVsZWFz
ZSB5b3VyIGVudGlyZSBhcHBsaWNhdGlvbiBlYWNoPGJyPiZndDsgJmd0OyB0aW1lIGZvdW5kLCBu
b3cgbXVsdGlwbGUgaXQgd2l0aCB0aGUgIyBvZiBjb21wb25lbnRzIGFwcGxpY2F0aW9uIGlzIHVz
aW5nPGJyPiZndDsgJmd0OyBhbmQgc2VlIGhvdyBtdWNoIGVmZm9ydCB5b3UgaGF2ZSBqdXN0IHRv
IG1haW50YWluIHN0YWJpbGl0eSBhbmQgc2VjdXJpdHkgaWY8YnI+Jmd0OyAmZ3Q7IHlvdSBlbWJl
ZCAzcmQgcGFydHkgY29tcG9uZW50cyB3aXRob3V0IHlvdXIgYXBwbGljYXRpb24uPGJyPiZndDsg
PGJyPiZndDsgWWVzLCBpZiB5b3UgdXNlIHBhY2thZ2UgWCB0aGVuIHlvdSdyZSB1c2luZyB0aGF0
IHNwZWNpZmljIHZlcnNpb24gd2l0aCBpdCdzPGJyPiZndDsgYmVoYXZpb3VyIGFuZCBBUEksIHRo
aXMgaXMgd2h5IGRlcGVuZGVuY2llcyBhcmVuJ3QgdXBkYXRlZCBsaWdodCBoZWFkZWRseSBidXQ8
YnI+Jmd0OyB3aXRoIHRlc3RpbmcgdG8gc2VlIHRoYXQgbm90aGluZyBicm9rZSAoc2luY2Ugc3R1
ZmYgZG9lcyBicmVhaywgZXZlbiBpbiBtaW5vcjxicj4mZ3Q7IHZlcnNpb24sIGFzIHdlIGxlYXZl
IGluIGEgbm90IHNvIHBlcmZlY3Qgd29ybGQpLjxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgPGJyPiZn
dDsgJmd0OyAmZ3Q7IFdoeSBkbyB3ZSBhdm9pZCAidG8gbWFpbnRhaW4gb3VyIG93biBwYWNrYWdp
bmciPyBJTUhPIE92aXJ0IG93bjxicj4mZ3Q7ICZndDsgJmd0OyBkZXBlbmRlbmNpZXM8YnI+Jmd0
OyAmZ3Q7ICZndDsgY291bGQgYmUgcGFja2VkIGluIHRoZSB3YXIsIGNhbid0IHRoZXk/PGJyPiZn
dDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IHllcyB0aGV5IGNvdWxkLCBidXQgdGhpcyBpcyBub3Qgc3Vp
dGFibGUgZm9yIGVudGVycHJpc2UgZ3JhZGU8YnI+Jmd0OyAmZ3Q7IGltcGxlbWVudGF0aW9ucywg
bWFpbmx5IHBlciB3aGF0IEkgZGVzY3JpYmVkIGFib3ZlLjxicj4mZ3Q7IDxicj4mZ3Q7IFNvcnJ5
IGJ1dCBBRkFJSyBlbnRlcnByaXNlIGdyYWRlIHNvZnR3YXJlIHJlbGVhc2UgZml4ZXMgZm9yIHRo
ZWlyIHNvZnR3YXJlPGJyPiZndDsgb24gYSB0aW1lbHkgYmFzaXMgYW5kIGhhdmUgcHJvY2Vzc2Vz
IGluIHBsYWNlIHRvIG1hbmFnZSB1cGdyYWRlcyBvZjxicj4mZ3Q7IGZ1bmN0aW9uYWxpdHkuPGJy
PiZndDsgPGJyPiZndDsgV2hhdCBjdXJyZW50bHkgaXMgZG9uZSBpcyByZWx5aW5nIG9uIGNvdXJ0
ZXN5IG9mIG90aGVyIHBlb3BsZSB0byByZWxlYXNlIGE8YnI+Jmd0OyAiZml4IiB0aGF0IGFscmVh
ZHkgZXhpc3RzIGEgbG9uZyB0aW1lLjxicj4mZ3Q7IEFuZCBvZiBjb3Vyc2UsIGFzIEkgbWVudGlv
bmVkLCB0aGUgYXBwbGljYXRpb24gbmVlZHMgdG8gYmUgdGVzdGVkIHdpdGggdGhlPGJyPiZndDsg
dXBkYXRlZCBsaWJyYXJ5Ljxicj4mZ3Q7IElNTyBuZWdsZWN0aW5nIHRoaXMgYW5kIGxlYXZpbmcg
dGhpcyBvdXQgb2YgYmFuZCBmb3IgImVudGVycHJpc2UgZ3JhZGUiPGJyPiZndDsgc29mdHdhcmUg
aXMgbXVjaCB3b3JzZSB0aGFuIGFjdHVhbGx5IHRlc3RpbmcgdG8gc2VlIHRoYXQgaXQgaXMgd29y
a2luZyBhbmQ8YnI+Jmd0OyBqdXN0IGxlYXZpbmcgaXQgYWxsIHRvIGNoYW5jZS48YnI+PGJyPuKA
jldlbGwsIHRha2UgdGhlIHJlY2VudCBleGFtcGxlIG9mIG9wZW5zc2wgaXNzdWUgdGhhdCB3YXMg
Zm91bmQuPGJyPk5vdywgaW1hZ2luZSB0aGF0IGFsbCBwcm9kdWN0cyB0aGF0IHVzZSBvcGVuc3Ns
IHNob3VsZCBoYXZlIGJlZW4gcmUtcmVsZWFzZWQuPGJyPkkgdGhpbmsgdGhpcyBpcyBlbm91Z2gg
dG8gdW5kZXJzdGFuZCBob3cgd3JvbmcgdGhpcyBpcy48YnI+PGJyPiZndDsgPGJyPiZndDsgJmd0
OyA8YnI+Jmd0OyAmZ3Q7IFJlZ2FyZHMsPGJyPiZndDsgJmd0OyBBbG9uPGJyPiZndDsgJmd0OyA8
YnI+Jmd0OyAmZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxicj4mZ3Q7ICZndDsgJmd0OyBfX19fX19f
X19fX19fX19fX19fXzxicj4mZ3Q7ICZndDsgJmd0OyBZZXZnZW55IFphc3BpdHNreTxicj4mZ3Q7
ICZndDsgJmd0OyBTZW5pb3IgU29mdHdhcmUgRW5naW5lZXI8YnI+Jmd0OyAmZ3Q7ICZndDsgUmVk
IEhhdCBJc3JhZWw8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7
ICZndDsgJmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPiZndDsgJmd0OyAmZ3Q7
IEZyb206ICJBbG9uIEJhci1MZXYiICZsdDthbG9uYmxAcmVkaGF0LmNvbSZndDs8YnI+Jmd0OyAm
Z3Q7ICZndDsgVG86ICJZZXZnZW55IFphc3BpdHNreSIgJmx0O3l6YXNwaXRzQHJlZGhhdC5jb20m
Z3Q7PGJyPiZndDsgJmd0OyAmZ3Q7IENjOiBkZXZlbEBvdmlydC5vcmc8YnI+Jmd0OyAmZ3Q7ICZn
dDsgU2VudDogU3VuZGF5LCBBcHJpbCAxMywgMjAxNCA3OjIyOjE4IFBNPGJyPiZndDsgJmd0OyAm
Z3Q7IFN1YmplY3Q6IFJlOiBbb3ZpcnQtZGV2ZWxdIGNvbW1vbnMtY29sbGVjdGlvbnMgdjQuMDxi
cj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IDxi
cj4mZ3Q7ICZndDsgJmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPiZndDsgJmd0
OyAmZ3Q7ICZndDsgRnJvbTogIllldmdlbnkgWmFzcGl0c2t5IiAmbHQ7eXphc3BpdHNAcmVkaGF0
LmNvbSZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogZGV2ZWxAb3ZpcnQub3JnPGJyPiZn
dDsgJmd0OyAmZ3Q7ICZndDsgU2VudDogU3VuZGF5LCBBcHJpbCAxMywgMjAxNCA3OjEzOjEwIFBN
PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogW292aXJ0LWRldmVsXSBjb21tb25zLWNv
bGxlY3Rpb25zIHY0LjA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsg
Jmd0OyBIaSBBbGwsPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZn
dDsgSSdkIGxpa2UgdG8gYWRkIHRoZSBuZXcgdmVyc2lvbiAoNC4wKSBvZiBBcGFjaGUgY29tbW9u
cy1jb2xsZWN0aW9uczxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxpYnJhcnk8YnI+Jmd0OyAmZ3Q7
ICZndDsgJmd0OyB0byB0aGUgZGVwZW5kZW5jaWVzIG9mIHRoZSBwcm9qZWN0ICh3ZSB1c2UgMy4x
IGN1cnJlbnRseSkuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIG5ldyB2ZXJzaW9uIHVzZXMg
dGhlIGdlbmVyaWNzIGZlYXR1cmVzIG9mIEphdmEgNSBzbyB0aGF0IG1ha2UgdGhlPGJyPiZndDsg
Jmd0OyAmZ3Q7ICZndDsgY29kZTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1vcmUgdHlwZSBzYWZl
LiBZb3UgY2FuIGZpbmQgdGhlIGZ1bGwgbGlzdCBvZiBjaGFuZ2VzIG9uPGJyPiZndDsgJmd0OyAm
Z3Q7ICZndDsgaHR0cHM6Ly9jb21tb25zLmFwYWNoZS5vcmcvcHJvcGVyL2NvbW1vbnMtY29sbGVj
dGlvbnMvcmVsZWFzZV80XzAuaHRtbC48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgbmV3IEFQ
SSBpcyBiYXNlZCBvbiB0aGUgb3JpZ2luYWwgYnV0IGl0IGlzbid0IGZ1bGx5IGNvbXBhdGlibGUg
d2l0aDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGl0Ljxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNv
IGluIG9yZGVyIHRvIG1ha2UgdGhlIG1pZ3JhdGlvbiB0byB0aGUgbmV3IEFQSSBlYXNpZXIsIHRo
ZSBwYWNrYWdlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgaGFzPGJyPiZndDsgJmd0OyAmZ3Q7ICZn
dDsgYmVlbiBjaGFuZ2VkIHRvIG9yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9uczQuIFRoYXQg
YWxsb3dzIGhhdmluZzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJvdGg8YnI+Jmd0OyAmZ3Q7ICZn
dDsgJmd0OyB2ZXJzaW9uIG9mIHRoZSBsaWJyYXJ5IGluIHRoZSBjbGFzc3BhdGggYXQgdGhlIHN0
YXJ0aW5nIHBvaW50IGFuZCBtb3ZlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgKHJlZmFjdG9yKSB0
b3dhcmRzIHRoZSBuZXcgdmVyc2lvbiBncmFkdWFsbHkuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg
PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBoYXZlIGNvdXBsZSBvZiBxdWVzdGlvbnMgcmVnYXJk
aW5nIHRoZSBuZXcgZGVwZW5kZW5jeTo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAxLiBJcyB0aGVy
ZSBhbnl0aGluZyB0aGF0IGNvdWxkIHByZXZlbnQgYWRkaW5nIHRoZSBuZXcgZGVwZW5kZW5jeT88
YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IFdlIHRyeSB0byBhdm9pZCBpbnRy
b2R1Y2luZyBvdXIgb3duIGRlcGVuZGVuY2llcywgaW4gdGhpcyBjYXNlIHdlIHVzZTxicj4mZ3Q7
ICZndDsgJmd0OyB3aGF0ZXZlciBqYm9zcyBwcm92aWRlcyB3aGljaCBpcyB2ZXJ5IGNvbWZvcnRh
YmxlIGFzIHdlIGRvIG5vdCBuZWVkIHRvPGJyPiZndDsgJmd0OyAmZ3Q7IG1haW50YWluIG91ciBv
d24gcGFja2FnaW5nLjxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgQ3VycmVu
dGx5IHRoZSBqYmVhcCBkb2VzIG5vdCBwcm92aWRlIDQuMCwgaXQgZG9lcyBzdXBwb3J0IDMuMi4x
LXJlZGhhdC0yLDxicj4mZ3Q7ICZndDsgJmd0OyBzbzxicj4mZ3Q7ICZndDsgJmd0OyBiZXR0ZXIg
dG8gYXZvaWQgdGhpcyB1bnRpbCB3ZSBzd2l0Y2ggdG8gbW9yZSByZWNlbnQgdmVyc2lvbiBvZiBq
Ym9zcy48YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IEFsdGVybmF0aXZlbHkg
d2UgY291bGQgZW5qb3kgc3RhbmRhbG9uZSBycG0gd2l0aGluIHJoZWwvY2VudG9zIGlmPGJyPiZn
dDsgJmd0OyAmZ3Q7IGF2YWlsYWJsZSw8YnI+Jmd0OyAmZ3Q7ICZndDsgaG93ZXZlciBub24gZXhp
c3QuPGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDIuIEkgZGlkIHRo
ZSBjaGFuZ2UgKGh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnLzI2NzQ1KS48YnI+Jmd0OyAmZ3Q7ICZn
dDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgdW5pdCB0ZXN0cyB0aGF0IHVzZSB0aGUgbmV3
IGRlcGVuZGVuY3kgcGFzcyBsb2NhbGx5IGFuZCBpbjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IEplbmtpbnM8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNw
OyZuYnNwOyBlbnZpcm9ubWVudHMuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsm
bmJzcDsgSG93ZXZlciB3aGVuIEkgdHJ5IHRvIHJ1biBhIGNvZGUgdGhhdCBpcyBkZXBlbmRlbnQg
b24gdGhlIG5ld2x5PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYWRk
ZWQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBsaWJyYXJ5IE5vQ2xh
c3NEZWZGb3VuZEVycm9yIGJlaW5nIHRocm93bi48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNw
OyZuYnNwOyZuYnNwOyBBbHNvIEkgY2FuJ3QgZmluZCBjb21tb25zLWNvbGxlY3Rpb25zNCBqYXIg
dW5kZXIgdGhlIGluc3RhbGxhdGlvbjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGRpcmVjdG9yeS4gSSB1c2UgIm1ha2UgY2xlYW4gaW5zdGFsbC1kZXYiIGNvbW1hbmQg
Zm9yIGJ1aWxkaW5nLjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAm
Z3Q7IFBsZWFzZSBhZHZpc2UuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyA8YnI+PC9ib2R5Pg==
----_com.android.email_1462209507407830--
1:14 a.m.
New subject: commons-collections v4.0
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Mike Kolesnik"
<mkolesni(a)redhat.com>
Cc: devel(a)ovirt.org
Sent: Thursday, May 8, 2014 1:11:41 AM
Subject: Re: [ovirt-devel] commons-collections v4.0
On the other hand, changing a jar in the runtime environment without
compiling and running test with the new jar could lead an application to
stop functioning in a customer environment.
Also not every bug found in a dependency jar would cause a problem in the
application. (An application might not use the problematic part of the
dependency.)
I'd better trust the test suite (automatic and manual) that we run on the
compiled application with all the dependencies that the developers choose at
the development time and then deliver that (with its dependencies as a
single package) to the customers.
Every bug in a dependency should be evaluated within the given application
scope and only if proven as the given application problem only then the
application should be released.
So what you basically claim is that java developers and technology is not mature enough to
keep backward compatibility, so each java developer should freeze a snapshot in time for
his application to work.
I truly hope this is not the case.
And for addressing your claim explicitly, what you can test at single point in time, does
not mean that it is definite as well, at customer site bugs may be found also in the
packages that you do test.
Sent from Samsung Mobile
-------- Original message --------
From: Alon Bar-Lev <alonbl(a)redhat.com>
Date: 07/05/2014 21:41 (GMT+02:00)
To: Mike Kolesnik <mkolesni(a)redhat.com>
Cc: Yevgeny Zaspitsky <yzaspits@redhat.com>,devel(a)ovirt.org
Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
> From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>, devel(a)ovirt.org
> Sent: Wednesday, May 7, 2014 9:34:03 PM
> Subject: Re: [ovirt-devel] commons-collections v4.0
>
> ----- Original Message -----
> >
> >
> > ----- Original Message -----
> > > From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > Cc: devel(a)ovirt.org
> > > Sent: Tuesday, April 22, 2014 11:39:11 AM
> > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > >
> > > That means that we manage 2 separate environments:
> > > 1. Development - relies on pom files. E.g. unit tests run with
> > > commons-collections v3.1 (and when I add v4.0) and succeed.
> >
> > devenv will use runtime option.
> > you are right about the unit tests, these relays on the poms.
>
> I use devenv and it always uses the dev option not the runtime.
> So basically developers are using the pom specified versions and not what
> used in runtime.
>
> Even more so, in runtime it highly depends on what OS you're using, so
> someone
> developing on F19 might not be using same versions as a developer on F20
> and
> both are probably very different versions than on RHEL/CentOS.
> I won't even mention other OS`s.
>
> >
> > > 2. Run-time - relies on JBoss own dependencies that bring
> > > commons-collection
> > > v3.2.1-redhat-2.
> >
> > in rhel case, yes.
> >
> > > This kind of discrepancies might be found in other libraries as we do
> > > not
> > > synchronize our pom files with the JBoss current version dependencies.
> > > IMHO that could lead to some very difficult bugs that we won't be
able
> > > to
> > > simulate in our unit tests.
> >
> > correct, but the java way to pull dependencies at will without being able
> > to
> > fix z-stream using central package management tools is more severe than
> > unit
> > tests not working/not working.
> >
> > for example, your application uses x.jar and actually delivers x.jar...
> > so
> > from release to eternity it is your responsibility to track x.jar for
> > severe
> > stability bugs and security bugs, and release your entire application
> > each
> > time found, now multiple it with the # of components application is using
> > and see how much effort you have just to maintain stability and security
> > if
> > you embed 3rd party components without your application.
>
> Yes, if you use package X then you're using that specific version with it's
> behaviour and API, this is why dependencies aren't updated light headedly
> but
> with testing to see that nothing broke (since stuff does break, even in
> minor
> version, as we leave in a not so perfect world).
>
> >
> > > Why do we avoid "to maintain our own packaging"? IMHO Ovirt own
> > > dependencies
> > > could be packed in the war, can't they?
> >
> > yes they could, but this is not suitable for enterprise grade
> > implementations, mainly per what I described above.
>
> Sorry but AFAIK enterprise grade software release fixes for their software
> on a timely basis and have processes in place to manage upgrades of
> functionality.
>
> What currently is done is relying on courtesy of other people to release a
> "fix" that already exists a long time.
> And of course, as I mentioned, the application needs to be tested with the
> updated library.
> IMO neglecting this and leaving this out of band for "enterprise grade"
> software is much worse than actually testing to see that it is working and
> just leaving it all to chance.
Well, take the recent example of openssl issue that was found.
Now, imagine that all products that use openssl should have been re-released.
I think this is enough to understand how wrong this is.
>
> >
> > Regards,
> > Alon
> >
> > > Best regards,
> > > ____________________
> > > Yevgeny Zaspitsky
> > > Senior Software Engineer
> > > Red Hat Israel
> > >
> > >
> > > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> > > Cc: devel(a)ovirt.org
> > > Sent: Sunday, April 13, 2014 7:22:18 PM
> > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> > > > To: devel(a)ovirt.org
> > > > Sent: Sunday, April 13, 2014 7:13:10 PM
> > > > Subject: [ovirt-devel] commons-collections v4.0
> > > >
> > > > Hi All,
> > > >
> > > > I'd like to add the new version (4.0) of Apache
commons-collections
> > > > library
> > > > to the dependencies of the project (we use 3.1 currently).
> > > > The new version uses the generics features of Java 5 so that make
the
> > > > code
> > > > more type safe. You can find the full list of changes on
> > > >
https://commons.apache.org/proper/commons-collections/release_4_0.html.
> > > > The new API is based on the original but it isn't fully
compatible
> > > > with
> > > > it.
> > > > So in order to make the migration to the new API easier, the package
> > > > has
> > > > been changed to org.apache.commons.collections4. That allows having
> > > > both
> > > > version of the library in the classpath at the starting point and
> > > > move
> > > > (refactor) towards the new version gradually.
> > > >
> > > > I have couple of questions regarding the new dependency:
> > > > 1. Is there anything that could prevent adding the new dependency?
> > >
> > > We try to avoid introducing our own dependencies, in this case we use
> > > whatever jboss provides which is very comfortable as we do not need to
> > > maintain our own packaging.
> > >
> > > Currently the jbeap does not provide 4.0, it does support
> > > 3.2.1-redhat-2,
> > > so
> > > better to avoid this until we switch to more recent version of jboss.
> > >
> > > Alternatively we could enjoy standalone rpm within rhel/centos if
> > > available,
> > > however non exist.
> > >
> > > > 2. I did the change (http://gerrit.ovirt.org/26745).
> > > > The unit tests that use the new dependency pass locally and in
> > > > Jenkins
> > > > environments.
> > > > However when I try to run a code that is dependent on the newly
> > > > added
> > > > library NoClassDefFoundError being thrown.
> > > > Also I can't find commons-collections4 jar under the
installation
> > > > directory. I use "make clean install-dev" command for
building.
> > > >
> > > > Please advise.
> >
>
7:18 a.m.
New subject: commons-collections v4.0
----- Original Message -----
----- Original Message -----
> From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Mike Kolesnik"
> <mkolesni(a)redhat.com>
> Cc: devel(a)ovirt.org
> Sent: Thursday, May 8, 2014 1:11:41 AM
> Subject: Re: [ovirt-devel] commons-collections v4.0
>
> On the other hand, changing a jar in the runtime environment without
> compiling and running test with the new jar could lead an application to
> stop functioning in a customer environment.
> Also not every bug found in a dependency jar would cause a problem in the
> application. (An application might not use the problematic part of the
> dependency.)
> I'd better trust the test suite (automatic and manual) that we run on the
> compiled application with all the dependencies that the developers choose
> at
> the development time and then deliver that (with its dependencies as a
> single package) to the customers.
> Every bug in a dependency should be evaluated within the given application
> scope and only if proven as the given application problem only then the
> application should be released.
So what you basically claim is that java developers and technology is not
mature enough to keep backward compatibility, so each java developer should
freeze a snapshot in time for his application to work.
I truly hope this is not the case.
There can always be regressions as you're well aware, and I don't know but
usually people who develop the libraries are not Einstein so yes, they do break
backwards compatibility on occasions, sometimes even on purpose (deprecation).
And for addressing your claim explicitly, what you can test at single point
in time, does not mean that it is definite as well, at customer site bugs
may be found also in the packages that you do test.
Well, when you test on site by dev & qa you make sure you send something to the
customer - X. When the dependencies are updated out of band, the customer
actually is using X'.
I can see at least 2 things wrong here:
1. You're putting the customer in a position of a tester for the X' application.
2. If customer finds a bug he actually found it on X', whereas the developer who
would be assigned to the bug could be using X'' by now.
If you're so keen on packaging a jar outside WAR file, we need to specify
explicit version and not >=.
>
>
> Sent from Samsung Mobile
>
> -------- Original message --------
> From: Alon Bar-Lev <alonbl(a)redhat.com>
> Date: 07/05/2014 21:41 (GMT+02:00)
> To: Mike Kolesnik <mkolesni(a)redhat.com>
> Cc: Yevgeny Zaspitsky <yzaspits@redhat.com>,devel(a)ovirt.org
> Subject: Re: [ovirt-devel] commons-collections v4.0
>
>
>
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > Cc: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>, devel(a)ovirt.org
> > Sent: Wednesday, May 7, 2014 9:34:03 PM
> > Subject: Re: [ovirt-devel] commons-collections v4.0
> >
> > ----- Original Message -----
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > > Cc: devel(a)ovirt.org
> > > > Sent: Tuesday, April 22, 2014 11:39:11 AM
> > > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > >
> > > > That means that we manage 2 separate environments:
> > > > 1. Development - relies on pom files. E.g. unit tests run with
> > > > commons-collections v3.1 (and when I add v4.0) and succeed.
> > >
> > > devenv will use runtime option.
> > > you are right about the unit tests, these relays on the poms.
> >
> > I use devenv and it always uses the dev option not the runtime.
> > So basically developers are using the pom specified versions and not what
> > used in runtime.
> >
> > Even more so, in runtime it highly depends on what OS you're using, so
> > someone
> > developing on F19 might not be using same versions as a developer on F20
> > and
> > both are probably very different versions than on RHEL/CentOS.
> > I won't even mention other OS`s.
> >
> > >
> > > > 2. Run-time - relies on JBoss own dependencies that bring
> > > > commons-collection
> > > > v3.2.1-redhat-2.
> > >
> > > in rhel case, yes.
> > >
> > > > This kind of discrepancies might be found in other libraries as we
do
> > > > not
> > > > synchronize our pom files with the JBoss current version
> > > > dependencies.
> > > > IMHO that could lead to some very difficult bugs that we won't
be
> > > > able
> > > > to
> > > > simulate in our unit tests.
> > >
> > > correct, but the java way to pull dependencies at will without being
> > > able
> > > to
> > > fix z-stream using central package management tools is more severe than
> > > unit
> > > tests not working/not working.
> > >
> > > for example, your application uses x.jar and actually delivers x.jar...
> > > so
> > > from release to eternity it is your responsibility to track x.jar for
> > > severe
> > > stability bugs and security bugs, and release your entire application
> > > each
> > > time found, now multiple it with the # of components application is
> > > using
> > > and see how much effort you have just to maintain stability and
> > > security
> > > if
> > > you embed 3rd party components without your application.
> >
> > Yes, if you use package X then you're using that specific version with
> > it's
> > behaviour and API, this is why dependencies aren't updated light headedly
> > but
> > with testing to see that nothing broke (since stuff does break, even in
> > minor
> > version, as we leave in a not so perfect world).
> >
> > >
> > > > Why do we avoid "to maintain our own packaging"? IMHO Ovirt
own
> > > > dependencies
> > > > could be packed in the war, can't they?
> > >
> > > yes they could, but this is not suitable for enterprise grade
> > > implementations, mainly per what I described above.
> >
> > Sorry but AFAIK enterprise grade software release fixes for their
> > software
> > on a timely basis and have processes in place to manage upgrades of
> > functionality.
> >
> > What currently is done is relying on courtesy of other people to release
> > a
> > "fix" that already exists a long time.
> > And of course, as I mentioned, the application needs to be tested with
> > the
> > updated library.
> > IMO neglecting this and leaving this out of band for "enterprise
grade"
> > software is much worse than actually testing to see that it is working
> > and
> > just leaving it all to chance.
>
> Well, take the recent example of openssl issue that was found.
> Now, imagine that all products that use openssl should have been
> re-released.
> I think this is enough to understand how wrong this is.
>
> >
> > >
> > > Regards,
> > > Alon
> > >
> > > > Best regards,
> > > > ____________________
> > > > Yevgeny Zaspitsky
> > > > Senior Software Engineer
> > > > Red Hat Israel
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > > To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> > > > Cc: devel(a)ovirt.org
> > > > Sent: Sunday, April 13, 2014 7:22:18 PM
> > > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> > > > > To: devel(a)ovirt.org
> > > > > Sent: Sunday, April 13, 2014 7:13:10 PM
> > > > > Subject: [ovirt-devel] commons-collections v4.0
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I'd like to add the new version (4.0) of Apache
commons-collections
> > > > > library
> > > > > to the dependencies of the project (we use 3.1 currently).
> > > > > The new version uses the generics features of Java 5 so that
make
> > > > > the
> > > > > code
> > > > > more type safe. You can find the full list of changes on
> > > > >
https://commons.apache.org/proper/commons-collections/release_4_0.html.
> > > > > The new API is based on the original but it isn't fully
compatible
> > > > > with
> > > > > it.
> > > > > So in order to make the migration to the new API easier, the
> > > > > package
> > > > > has
> > > > > been changed to org.apache.commons.collections4. That allows
having
> > > > > both
> > > > > version of the library in the classpath at the starting point
and
> > > > > move
> > > > > (refactor) towards the new version gradually.
> > > > >
> > > > > I have couple of questions regarding the new dependency:
> > > > > 1. Is there anything that could prevent adding the new
dependency?
> > > >
> > > > We try to avoid introducing our own dependencies, in this case we
use
> > > > whatever jboss provides which is very comfortable as we do not need
> > > > to
> > > > maintain our own packaging.
> > > >
> > > > Currently the jbeap does not provide 4.0, it does support
> > > > 3.2.1-redhat-2,
> > > > so
> > > > better to avoid this until we switch to more recent version of
jboss.
> > > >
> > > > Alternatively we could enjoy standalone rpm within rhel/centos if
> > > > available,
> > > > however non exist.
> > > >
> > > > > 2. I did the change (http://gerrit.ovirt.org/26745).
> > > > > The unit tests that use the new dependency pass locally and
in
> > > > > Jenkins
> > > > > environments.
> > > > > However when I try to run a code that is dependent on the
newly
> > > > > added
> > > > > library NoClassDefFoundError being thrown.
> > > > > Also I can't find commons-collections4 jar under the
> > > > > installation
> > > > > directory. I use "make clean install-dev" command
for building.
> > > > >
> > > > > Please advise.
> > >
> >
>
9:43 a.m.
New subject: commons-collections v4.0
----- Original Message -----
From: "Mike Kolesnik" <mkolesni(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "yzaspits" <yzaspits(a)redhat.com>, devel(a)ovirt.org
Sent: Thursday, May 8, 2014 7:18:51 AM
Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
>
>
> ----- Original Message -----
> > From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> > To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Mike
Kolesnik"
> > <mkolesni(a)redhat.com>
> > Cc: devel(a)ovirt.org
> > Sent: Thursday, May 8, 2014 1:11:41 AM
> > Subject: Re: [ovirt-devel] commons-collections v4.0
> >
> > On the other hand, changing a jar in the runtime environment without
> > compiling and running test with the new jar could lead an application to
> > stop functioning in a customer environment.
> > Also not every bug found in a dependency jar would cause a problem in the
> > application. (An application might not use the problematic part of the
> > dependency.)
> > I'd better trust the test suite (automatic and manual) that we run on the
> > compiled application with all the dependencies that the developers choose
> > at
> > the development time and then deliver that (with its dependencies as a
> > single package) to the customers.
> > Every bug in a dependency should be evaluated within the given
> > application
> > scope and only if proven as the given application problem only then the
> > application should be released.
>
> So what you basically claim is that java developers and technology is not
> mature enough to keep backward compatibility, so each java developer should
> freeze a snapshot in time for his application to work.
>
> I truly hope this is not the case.
There can always be regressions as you're well aware, and I don't know but
usually people who develop the libraries are not Einstein so yes, they do
break
backwards compatibility on occasions, sometimes even on purpose
(deprecation).
>
> And for addressing your claim explicitly, what you can test at single point
> in time, does not mean that it is definite as well, at customer site bugs
> may be found also in the packages that you do test.
Well, when you test on site by dev & qa you make sure you send something to
the
customer - X. When the dependencies are updated out of band, the customer
actually is using X'.
I can see at least 2 things wrong here:
1. You're putting the customer in a position of a tester for the X'
application.
2. If customer finds a bug he actually found it on X', whereas the developer
who
would be assigned to the bug could be using X'' by now.
If you're so keen on packaging a jar outside WAR file, we need to specify
explicit version and not >=.
Explicit version is at if you pack it within your application, there is no point in that.
Think of how RHEL is provided, think of Fedora, in all cases there are components working
together and each can be updated independently, and amazingly - it works. You can think of
Windows with all of its libraries and interfaces (Microsoft or 3rd party), that
application use, and it does work without every [sane] application pulls the entire
dependencies.
For some reason only people with Java background (including the J2EE designers) assume
that Java developers cannot be trusted for not breaking backward compatibility in minor
versions. This is not technical assumption but human assumption, as there is no technical
reason for Java library to break backward compatibility within minor releases, so what
does it tells us about what Java developers thinks of them-selves?
Java will be ready for enterprise only when this is resolved. I hope all the dependencies
we are using are at the quality level that enables us to to trust their developers.
>
> >
> >
> > Sent from Samsung Mobile
> >
> > -------- Original message --------
> > From: Alon Bar-Lev <alonbl(a)redhat.com>
> > Date: 07/05/2014 21:41 (GMT+02:00)
> > To: Mike Kolesnik <mkolesni(a)redhat.com>
> > Cc: Yevgeny Zaspitsky <yzaspits@redhat.com>,devel(a)ovirt.org
> > Subject: Re: [ovirt-devel] commons-collections v4.0
> >
> >
> >
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > Cc: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>,
devel(a)ovirt.org
> > > Sent: Wednesday, May 7, 2014 9:34:03 PM
> > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > >
> > > ----- Original Message -----
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> > > > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > > > Cc: devel(a)ovirt.org
> > > > > Sent: Tuesday, April 22, 2014 11:39:11 AM
> > > > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > > >
> > > > > That means that we manage 2 separate environments:
> > > > > 1. Development - relies on pom files. E.g. unit tests run with
> > > > > commons-collections v3.1 (and when I add v4.0) and succeed.
> > > >
> > > > devenv will use runtime option.
> > > > you are right about the unit tests, these relays on the poms.
> > >
> > > I use devenv and it always uses the dev option not the runtime.
> > > So basically developers are using the pom specified versions and not
> > > what
> > > used in runtime.
> > >
> > > Even more so, in runtime it highly depends on what OS you're using,
so
> > > someone
> > > developing on F19 might not be using same versions as a developer on
> > > F20
> > > and
> > > both are probably very different versions than on RHEL/CentOS.
> > > I won't even mention other OS`s.
> > >
> > > >
> > > > > 2. Run-time - relies on JBoss own dependencies that bring
> > > > > commons-collection
> > > > > v3.2.1-redhat-2.
> > > >
> > > > in rhel case, yes.
> > > >
> > > > > This kind of discrepancies might be found in other libraries as
we
> > > > > do
> > > > > not
> > > > > synchronize our pom files with the JBoss current version
> > > > > dependencies.
> > > > > IMHO that could lead to some very difficult bugs that we
won't be
> > > > > able
> > > > > to
> > > > > simulate in our unit tests.
> > > >
> > > > correct, but the java way to pull dependencies at will without being
> > > > able
> > > > to
> > > > fix z-stream using central package management tools is more severe
> > > > than
> > > > unit
> > > > tests not working/not working.
> > > >
> > > > for example, your application uses x.jar and actually delivers
> > > > x.jar...
> > > > so
> > > > from release to eternity it is your responsibility to track x.jar
for
> > > > severe
> > > > stability bugs and security bugs, and release your entire
application
> > > > each
> > > > time found, now multiple it with the # of components application is
> > > > using
> > > > and see how much effort you have just to maintain stability and
> > > > security
> > > > if
> > > > you embed 3rd party components without your application.
> > >
> > > Yes, if you use package X then you're using that specific version
with
> > > it's
> > > behaviour and API, this is why dependencies aren't updated light
> > > headedly
> > > but
> > > with testing to see that nothing broke (since stuff does break, even in
> > > minor
> > > version, as we leave in a not so perfect world).
> > >
> > > >
> > > > > Why do we avoid "to maintain our own packaging"? IMHO
Ovirt own
> > > > > dependencies
> > > > > could be packed in the war, can't they?
> > > >
> > > > yes they could, but this is not suitable for enterprise grade
> > > > implementations, mainly per what I described above.
> > >
> > > Sorry but AFAIK enterprise grade software release fixes for their
> > > software
> > > on a timely basis and have processes in place to manage upgrades of
> > > functionality.
> > >
> > > What currently is done is relying on courtesy of other people to
> > > release
> > > a
> > > "fix" that already exists a long time.
> > > And of course, as I mentioned, the application needs to be tested with
> > > the
> > > updated library.
> > > IMO neglecting this and leaving this out of band for "enterprise
grade"
> > > software is much worse than actually testing to see that it is working
> > > and
> > > just leaving it all to chance.
> >
> > Well, take the recent example of openssl issue that was found.
> > Now, imagine that all products that use openssl should have been
> > re-released.
> > I think this is enough to understand how wrong this is.
> >
> > >
> > > >
> > > > Regards,
> > > > Alon
> > > >
> > > > > Best regards,
> > > > > ____________________
> > > > > Yevgeny Zaspitsky
> > > > > Senior Software Engineer
> > > > > Red Hat Israel
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > > > To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> > > > > Cc: devel(a)ovirt.org
> > > > > Sent: Sunday, April 13, 2014 7:22:18 PM
> > > > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Yevgeny Zaspitsky"
<yzaspits(a)redhat.com>
> > > > > > To: devel(a)ovirt.org
> > > > > > Sent: Sunday, April 13, 2014 7:13:10 PM
> > > > > > Subject: [ovirt-devel] commons-collections v4.0
> > > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > I'd like to add the new version (4.0) of Apache
> > > > > > commons-collections
> > > > > > library
> > > > > > to the dependencies of the project (we use 3.1 currently).
> > > > > > The new version uses the generics features of Java 5 so
that make
> > > > > > the
> > > > > > code
> > > > > > more type safe. You can find the full list of changes on
> > > > > >
https://commons.apache.org/proper/commons-collections/release_4_0.html.
> > > > > > The new API is based on the original but it isn't
fully
> > > > > > compatible
> > > > > > with
> > > > > > it.
> > > > > > So in order to make the migration to the new API easier,
the
> > > > > > package
> > > > > > has
> > > > > > been changed to org.apache.commons.collections4. That
allows
> > > > > > having
> > > > > > both
> > > > > > version of the library in the classpath at the starting
point and
> > > > > > move
> > > > > > (refactor) towards the new version gradually.
> > > > > >
> > > > > > I have couple of questions regarding the new dependency:
> > > > > > 1. Is there anything that could prevent adding the new
> > > > > > dependency?
> > > > >
> > > > > We try to avoid introducing our own dependencies, in this case
we
> > > > > use
> > > > > whatever jboss provides which is very comfortable as we do not
need
> > > > > to
> > > > > maintain our own packaging.
> > > > >
> > > > > Currently the jbeap does not provide 4.0, it does support
> > > > > 3.2.1-redhat-2,
> > > > > so
> > > > > better to avoid this until we switch to more recent version of
> > > > > jboss.
> > > > >
> > > > > Alternatively we could enjoy standalone rpm within rhel/centos
if
> > > > > available,
> > > > > however non exist.
> > > > >
> > > > > > 2. I did the change (http://gerrit.ovirt.org/26745).
> > > > > > The unit tests that use the new dependency pass locally
and in
> > > > > > Jenkins
> > > > > > environments.
> > > > > > However when I try to run a code that is dependent on
the
> > > > > > newly
> > > > > > added
> > > > > > library NoClassDefFoundError being thrown.
> > > > > > Also I can't find commons-collections4 jar under
the
> > > > > > installation
> > > > > > directory. I use "make clean install-dev"
command for
> > > > > > building.
> > > > > >
> > > > > > Please advise.
> > > >
> > >
> >
>
3851
days inactive
3852
days old
3 comments
3 participants
participants (3)
-
Alon Bar-Lev -
Mike Kolesnik -
Yevgeny Zaspitsky