From tomasz-kolek at o2.pl Mon Mar 10 15:56:42 2014 Content-Type: multipart/mixed; boundary="===============5551292169327908330==" MIME-Version: 1.0 From: =?utf-8?q?Tomasz_Ko=C5=82ek_=3Ctomasz-kolek_at_o2=2Epl=3E?= To: users at ovirt.org Subject: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Mon, 10 Mar 2014 20:56:28 +0100 Message-ID: <000601cf3c9a$d37fec40$7a7fc4c0$@o2.pl> --===============5551292169327908330== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multipart message in MIME format. ------=3D_NextPart_000_0007_01CF3CA3.354BF560 Content-Type: text/plain; charset=3D"iso-8859-2" Content-Transfer-Encoding: 7bit Hi = I'd like to contribute (within GSOC) in idea: Gerrit add potential reviewers. Maybe at first I'll introduce myself. I'm Tomek, student from Poland. I study Computer Science at University of Wroclaw. The next year will be last year of my first degree study, I hope. As a python programmer I'm working since one year at Nokia Solutions and Networks (don't worry I intend to change my job to another or to participation at GSOC). Every day at work and school I'm using version control system (Git and SVN). At work we were using to Gerrit as a review system but currently we're using JIRA to report review statuses. I love spend my free time in mountains (mainly polish - Tatras mountains). That's all about me. I've got a few questions about project description. Please tell me if my problem's understanding is good or not. We need to add a few flags/methods to git review module. This flags should allow to add potential reviewers in gerrit. So: Let's assume that we've got special flags for this operations. What's next? 1. In gerrit system we need to add special place for potential reviewers? 2. Potential reviewers should agree that they want to review? 3. We can have more than one accepted reviewer? I know above questions might seem chaotic but I think answers allow me to better understanding Yours needments Best regards Tomasz Kolek ------=3D_NextPart_000_0007_01CF3CA3.354BF560 Content-Type: text/html; charset=3D"iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi

I'd like to contribute (within GSOC) in idea: Gerrit add =3D potential reviewers.

Maybe at first I’ll introduce =3D myself.
I'm Tomek, student from Poland. I study Computer Science at =3D University of Wroclaw. The next year will be last year of my first =3D degree study, I hope.
As a python programmer I'm working since one =3D year at Nokia Solutions and Networks (don't worry I intend to change my =3D job to another or to participation at GSOC). Every day at work and =3D school I'm using version control system (Git and SVN). At work we were =3D using to Gerrit as a review system but currently we're using JIRA to =3D report review statuses.
I love spend my free time in mountains =3D (mainly polish - Tatras mountains).
That's all about me.

I've =3D got a few questions about project description.
Please tell me if my =3D problem's understanding is good or not.
We need to add a few =3D flags/methods to git review module. This flags should allow to add =3D potential reviewers in gerrit.
So:
Let's assume that we've got =3D special flags for this operations. What's next?
1. In gerrit system =3D we need to add special place for potential reviewers?
2. Potential =3D reviewers should agree that they want to review?
3. We can have more =3D than one accepted reviewer?

I know above questions might seem =3D chaotic but I think answers allow me to better understanding Yours =3D needments

Best regards
Tomasz =3D Kolek

------=3D_NextPart_000_0007_01CF3CA3.354BF560-- --===============5551292169327908330== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpcGFydCBtZXNzYWdlIGluIE1JTUUgZm9ybWF0LgoKLS0tLS0tPV9OZXh0 UGFydF8wMDBfMDAwN18wMUNGM0NBMy4zNTRCRjU2MApDb250ZW50LVR5cGU6IHRleHQvcGxhaW47 CgljaGFyc2V0PSJpc28tODg1OS0yIgpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0CgpI aSAKCkknZCBsaWtlIHRvIGNvbnRyaWJ1dGUgKHdpdGhpbiBHU09DKSBpbiBpZGVhOiBHZXJyaXQg YWRkIHBvdGVudGlhbApyZXZpZXdlcnMuCgpNYXliZSBhdCBmaXJzdCBJJ2xsIGludHJvZHVjZSBt eXNlbGYuCkknbSBUb21laywgc3R1ZGVudCBmcm9tIFBvbGFuZC4gSSBzdHVkeSBDb21wdXRlciBT Y2llbmNlIGF0IFVuaXZlcnNpdHkgb2YKV3JvY2xhdy4gVGhlIG5leHQgeWVhciB3aWxsIGJlIGxh c3QgeWVhciBvZiBteSBmaXJzdCBkZWdyZWUgc3R1ZHksIEkgaG9wZS4KQXMgYSBweXRob24gcHJv Z3JhbW1lciBJJ20gd29ya2luZyBzaW5jZSBvbmUgeWVhciBhdCBOb2tpYSBTb2x1dGlvbnMgYW5k Ck5ldHdvcmtzIChkb24ndCB3b3JyeSBJIGludGVuZCB0byBjaGFuZ2UgbXkgam9iIHRvIGFub3Ro ZXIgb3IgdG8KcGFydGljaXBhdGlvbiBhdCBHU09DKS4gRXZlcnkgZGF5IGF0IHdvcmsgYW5kIHNj aG9vbCBJJ20gdXNpbmcgdmVyc2lvbgpjb250cm9sIHN5c3RlbSAoR2l0IGFuZCBTVk4pLiBBdCB3 b3JrIHdlIHdlcmUgdXNpbmcgdG8gR2Vycml0IGFzIGEgcmV2aWV3CnN5c3RlbSBidXQgY3VycmVu dGx5IHdlJ3JlIHVzaW5nIEpJUkEgdG8gcmVwb3J0IHJldmlldyBzdGF0dXNlcy4KSSBsb3ZlIHNw ZW5kIG15IGZyZWUgdGltZSBpbiBtb3VudGFpbnMgKG1haW5seSBwb2xpc2ggLSBUYXRyYXMgbW91 bnRhaW5zKS4KVGhhdCdzIGFsbCBhYm91dCBtZS4KCkkndmUgZ290IGEgZmV3IHF1ZXN0aW9ucyBh Ym91dCBwcm9qZWN0IGRlc2NyaXB0aW9uLgpQbGVhc2UgdGVsbCBtZSBpZiBteSBwcm9ibGVtJ3Mg dW5kZXJzdGFuZGluZyBpcyBnb29kIG9yIG5vdC4KV2UgbmVlZCB0byBhZGQgYSBmZXcgZmxhZ3Mv bWV0aG9kcyB0byBnaXQgcmV2aWV3IG1vZHVsZS4gVGhpcyBmbGFncyBzaG91bGQKYWxsb3cgdG8g YWRkIHBvdGVudGlhbCByZXZpZXdlcnMgaW4gZ2Vycml0LgpTbzoKTGV0J3MgYXNzdW1lIHRoYXQg d2UndmUgZ290IHNwZWNpYWwgZmxhZ3MgZm9yIHRoaXMgb3BlcmF0aW9ucy4gV2hhdCdzIG5leHQ/ CjEuIEluIGdlcnJpdCBzeXN0ZW0gd2UgbmVlZCB0byBhZGQgc3BlY2lhbCBwbGFjZSBmb3IgcG90 ZW50aWFsIHJldmlld2Vycz8KMi4gUG90ZW50aWFsIHJldmlld2VycyBzaG91bGQgYWdyZWUgdGhh dCB0aGV5IHdhbnQgdG8gcmV2aWV3PwozLiBXZSBjYW4gaGF2ZSBtb3JlIHRoYW4gb25lIGFjY2Vw dGVkIHJldmlld2VyPwoKSSBrbm93IGFib3ZlIHF1ZXN0aW9ucyBtaWdodCBzZWVtIGNoYW90aWMg YnV0IEkgdGhpbmsgYW5zd2VycyBhbGxvdyBtZSB0bwpiZXR0ZXIgdW5kZXJzdGFuZGluZyBZb3Vy cyBuZWVkbWVudHMKCkJlc3QgcmVnYXJkcwpUb21hc3ogS29sZWsKCgotLS0tLS09X05leHRQYXJ0 XzAwMF8wMDA3XzAxQ0YzQ0EzLjM1NEJGNTYwCkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOwoJY2hh cnNldD0iaXNvLTg4NTktMiIKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50 YWJsZQoKPGh0bWwgeG1sbnM6dj0zRCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgPQp4 bWxuczpvPTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgPQp4bWxu czp3PTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiID0KeG1sbnM6bT0z RCJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiID0KeG1s bnM9M0QiaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgPQpodHRw LWVxdWl2PTNEQ29udGVudC1UeXBlIGNvbnRlbnQ9M0QidGV4dC9odG1sOyA9CmNoYXJzZXQ9M0Rp c28tODg1OS0yIj48bWV0YSBuYW1lPTNER2VuZXJhdG9yIGNvbnRlbnQ9M0QiTWljcm9zb2Z0IFdv cmQgPQoxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0KLyogRm9udCBEZWZpbml0aW9u cyAqLwpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbAoJe21hcmdpbjowaW47CgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7Cglmb250LXNpemU6MTEuMHB0OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsKCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu awoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOmJsdWU7Cgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6cHVycGxlOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9CnNwYW4uU3R5bHdpYWRvbW9jaWUtbWFpbDE3Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cgljb2xvcjp3aW5k b3d0ZXh0O30KLk1zb0NocERlZmF1bHQKCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsKCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9CkBwYWdlIFdvcmRTZWN0aW9uMQoJe3NpemU6OC41aW4gMTEuMGluOwoJbWFyZ2luOjcw Ljg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PTNEImVkaXQiIHNwaWRtYXg9M0QiMTAyNiIgLz4KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PTNEImVk aXQiPgo8bzppZG1hcCB2OmV4dD0zRCJlZGl0IiBkYXRhPTNEIjEiIC8+CjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz0zRFBMIGxpbms9M0RibHVlID0K dmxpbms9M0RwdXJwbGU+PGRpdiBjbGFzcz0zRFdvcmRTZWN0aW9uMT48cCBjbGFzcz0zRE1zb05v cm1hbD48c3BhbiA9Cmxhbmc9M0RFTi1VUz5IaSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9M0RNc29Ob3JtYWw+PHNwYW4gPQpsYW5nPTNERU4tVVM+SSdkIGxpa2UgdG8gY29udHJpYnV0 ZSAod2l0aGluIEdTT0MpIGluIGlkZWE6IEdlcnJpdCBhZGQgPQpwb3RlbnRpYWwgcmV2aWV3ZXJz Ljxicj48YnI+TWF5YmUgYXQgZmlyc3QgSSYjODIxNztsbCBpbnRyb2R1Y2UgPQpteXNlbGYuPGJy PkknbSBUb21laywgc3R1ZGVudCBmcm9tIFBvbGFuZC4gSSBzdHVkeSBDb21wdXRlciBTY2llbmNl IGF0ID0KVW5pdmVyc2l0eSBvZiBXcm9jbGF3LiBUaGUgbmV4dCB5ZWFyIHdpbGwgYmUgbGFzdCB5 ZWFyIG9mIG15IGZpcnN0ID0KZGVncmVlIHN0dWR5LCBJIGhvcGUuPGJyPkFzIGEgcHl0aG9uIHBy b2dyYW1tZXIgSSdtIHdvcmtpbmcgc2luY2Ugb25lID0KeWVhciBhdCBOb2tpYSBTb2x1dGlvbnMg YW5kIE5ldHdvcmtzIChkb24ndCB3b3JyeSBJIGludGVuZCB0byBjaGFuZ2UgbXkgPQpqb2IgdG8g YW5vdGhlciBvciB0byBwYXJ0aWNpcGF0aW9uIGF0IEdTT0MpLiBFdmVyeSBkYXkgYXQgd29yayBh bmQgPQpzY2hvb2wgSSdtIHVzaW5nIHZlcnNpb24gY29udHJvbCBzeXN0ZW0gKEdpdCBhbmQgU1ZO KS4gQXQgd29yayB3ZSB3ZXJlID0KdXNpbmcgdG8gR2Vycml0IGFzIGEgcmV2aWV3IHN5c3RlbSBi dXQgY3VycmVudGx5IHdlJ3JlIHVzaW5nIEpJUkEgdG8gPQpyZXBvcnQgcmV2aWV3IHN0YXR1c2Vz Ljxicj5JIGxvdmUgc3BlbmQgbXkgZnJlZSB0aW1lIGluIG1vdW50YWlucyA9CihtYWlubHkgcG9s aXNoIC0gVGF0cmFzIG1vdW50YWlucykuPGJyPlRoYXQncyBhbGwgYWJvdXQgbWUuPGJyPjxicj5J J3ZlID0KZ290IGEgZmV3IHF1ZXN0aW9ucyBhYm91dCBwcm9qZWN0IGRlc2NyaXB0aW9uLjxicj5Q bGVhc2UgdGVsbCBtZSBpZiBteSA9CnByb2JsZW0ncyB1bmRlcnN0YW5kaW5nIGlzIGdvb2Qgb3Ig bm90Ljxicj5XZSBuZWVkIHRvIGFkZCBhIGZldyA9CmZsYWdzL21ldGhvZHMgdG8gZ2l0IHJldmll dyBtb2R1bGUuIFRoaXMgZmxhZ3Mgc2hvdWxkIGFsbG93IHRvIGFkZCA9CnBvdGVudGlhbCByZXZp ZXdlcnMgaW4gZ2Vycml0Ljxicj5Tbzo8YnI+TGV0J3MgYXNzdW1lIHRoYXQgd2UndmUgZ290ID0K c3BlY2lhbCBmbGFncyBmb3IgdGhpcyBvcGVyYXRpb25zLiBXaGF0J3MgbmV4dD88YnI+MS4gSW4g Z2Vycml0IHN5c3RlbSA9CndlIG5lZWQgdG8gYWRkIHNwZWNpYWwgcGxhY2UgZm9yIHBvdGVudGlh bCByZXZpZXdlcnM/PGJyPjIuIFBvdGVudGlhbCA9CnJldmlld2VycyBzaG91bGQgYWdyZWUgdGhh dCB0aGV5IHdhbnQgdG8gcmV2aWV3Pzxicj4zLiBXZSBjYW4gaGF2ZSBtb3JlID0KdGhhbiBvbmUg YWNjZXB0ZWQgcmV2aWV3ZXI/PGJyPjxicj5JIGtub3cgYWJvdmUgcXVlc3Rpb25zIG1pZ2h0IHNl ZW0gPQpjaGFvdGljIGJ1dCBJIHRoaW5rIGFuc3dlcnMgYWxsb3cgbWUgdG8gYmV0dGVyIHVuZGVy c3RhbmRpbmcgWW91cnMgPQpuZWVkbWVudHM8YnI+PGJyPkJlc3QgcmVnYXJkczxicj5Ub21hc3og PQpLb2xlazxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPgotLS0tLS09 X05leHRQYXJ0XzAwMF8wMDA3XzAxQ0YzQ0EzLjM1NEJGNTYwLS0KCg== --===============5551292169327908330==-- From eedri at redhat.com Tue Mar 11 10:37:39 2014 Content-Type: multipart/mixed; boundary="===============5167272706616946294==" MIME-Version: 1.0 From: Eyal Edri To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 10:37:22 -0400 Message-ID: <117854021.2029691.1394548642178.JavaMail.zimbra@redhat.com> In-Reply-To: 000601cf3c9a$d37fec40$7a7fc4c0$@o2.pl --===============5167272706616946294== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Tomasz Ko=C5=82ek" > To: users(a)ovirt.org > Sent: Monday, March 10, 2014 9:56:28 PM > Subject: [Users] [GSOC][Gerrit] add potential reviewers - questions > = > = > = > Hi > = > I'd like to contribute (within GSOC) in idea: Gerrit add potential review= ers. > = > Maybe at first I=E2=80=99ll introduce myself. > I'm Tomek, student from Poland. I study Computer Science at University of > Wroclaw. The next year will be last year of my first degree study, I hope. > As a python programmer I'm working since one year at Nokia Solutions and > Networks (don't worry I intend to change my job to another or to > participation at GSOC). Every day at work and school I'm using version > control system (Git and SVN). At work we were using to Gerrit as a review > system but currently we're using JIRA to report review statuses. > I love spend my free time in mountains (mainly polish - Tatras mountains). > That's all about me. > = > I've got a few questions about project description. > Please tell me if my problem's understanding is good or not. > We need to add a few flags/methods to git review module. This flags should > allow to add potential reviewers in gerrit. > So: > Let's assume that we've got special flags for this operations. What's nex= t? > 1. In gerrit system we need to add special place for potential reviewers? > 2. Potential reviewers should agree that they want to review? > 3. We can have more than one accepted reviewer? Hi Tomasz, I'm not sure i understood exactly what you mean by 'potential reviewers'. do want gerrit (hook?) to automatically add reviewers to a patch according = to the code sent? so in fact you'll have a place somewhere for mapping code & specific develo= pers? cause if you mean by adding reviewers to a patch, that's easily done by jus= t clicking the '+' sign on each patch. those reviewers should have logged in at least once to gerrit.ovirt.org in = order to be in the list of potential viewers, and they don't require any special permissions to review with +1/-1 any pat= ch sent. you can add as many reviewers as you want to a patch. does that answer your question? Eyal. > = > I know above questions might seem chaotic but I think answers allow me to > better understanding Yours needments > = > Best regards > Tomasz Kolek > = > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >=20 --===============5167272706616946294==-- From mbourvin at redhat.com Tue Mar 11 10:53:41 2014 Content-Type: multipart/mixed; boundary="===============5621235268239544088==" MIME-Version: 1.0 From: Meital Bourvine To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 10:53:24 -0400 Message-ID: <1756612588.2041647.1394549604045.JavaMail.zimbra@redhat.com> In-Reply-To: 117854021.2029691.1394548642178.JavaMail.zimbra@redhat.com --===============5621235268239544088== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Eyal, I think that he's asking about [1]. As far as I understand, the idea is to automatically get the reviewers name= s, with commands like `git blame`, or from gerrit - get previous reviewers = to the same file/module... Adding Maor, since he might have some additional info. [1] http://www.ovirt.org/Summer_of_Code#Idea:_Gerrit_add_potential_reviewers ----- Original Message ----- > From: "Eyal Edri" > To: "Tomasz Ko=C5=82ek" > Cc: users(a)ovirt.org, "infra" > Sent: Tuesday, March 11, 2014 4:37:22 PM > Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > = > = > = > ----- Original Message ----- > > From: "Tomasz Ko=C5=82ek" > > To: users(a)ovirt.org > > Sent: Monday, March 10, 2014 9:56:28 PM > > Subject: [Users] [GSOC][Gerrit] add potential reviewers - questions > > = > > = > > = > > Hi > > = > > I'd like to contribute (within GSOC) in idea: Gerrit add potential > > reviewers. > > = > > Maybe at first I=E2=80=99ll introduce myself. > > I'm Tomek, student from Poland. I study Computer Science at University = of > > Wroclaw. The next year will be last year of my first degree study, I ho= pe. > > As a python programmer I'm working since one year at Nokia Solutions and > > Networks (don't worry I intend to change my job to another or to > > participation at GSOC). Every day at work and school I'm using version > > control system (Git and SVN). At work we were using to Gerrit as a revi= ew > > system but currently we're using JIRA to report review statuses. > > I love spend my free time in mountains (mainly polish - Tatras mountain= s). > > That's all about me. > > = > > I've got a few questions about project description. > > Please tell me if my problem's understanding is good or not. > > We need to add a few flags/methods to git review module. This flags sho= uld > > allow to add potential reviewers in gerrit. > > So: > > Let's assume that we've got special flags for this operations. What's n= ext? > > 1. In gerrit system we need to add special place for potential reviewer= s? > > 2. Potential reviewers should agree that they want to review? > > 3. We can have more than one accepted reviewer? > = > Hi Tomasz, > I'm not sure i understood exactly what you mean by 'potential reviewers'. > do want gerrit (hook?) to automatically add reviewers to a patch accordin= g to > the code sent? > so in fact you'll have a place somewhere for mapping code & specific > developers? > = > cause if you mean by adding reviewers to a patch, that's easily done by j= ust > clicking the '+' sign on each patch. > those reviewers should have logged in at least once to gerrit.ovirt.org in > order to be in the list of potential viewers, > and they don't require any special permissions to review with +1/-1 any p= atch > sent. > you can add as many reviewers as you want to a patch. > = > does that answer your question? > = > Eyal. > = > = > = > > = > > I know above questions might seem chaotic but I think answers allow me = to > > better understanding Yours needments > > = > > Best regards > > Tomasz Kolek > > = > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > = > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >=20 --===============5621235268239544088==-- From ewoud+ovirt at kohlvanwijngaarden.nl Tue Mar 11 11:06:11 2014 Content-Type: multipart/mixed; boundary="===============5467377934649383851==" MIME-Version: 1.0 From: Ewoud Kohl van Wijngaarden To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 16:06:00 +0100 Message-ID: <20140311150600.GS5296@bogey.xentower.nl> In-Reply-To: 117854021.2029691.1394548642178.JavaMail.zimbra@redhat.com --===============5467377934649383851== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: > > Tomasz Ko=C5=82ek wrote: > > = > > I've got a few questions about project description. > > Please tell me if my problem's understanding is good or not. > > We need to add a few flags/methods to git review module. This flags sho= uld > > allow to add potential reviewers in gerrit. > > So: > > Let's assume that we've got special flags for this operations. What's n= ext? > > 1. In gerrit system we need to add special place for potential reviewer= s? > > 2. Potential reviewers should agree that they want to review? > > 3. We can have more than one accepted reviewer? > = > I'm not sure i understood exactly what you mean by 'potential > reviewers'. do want gerrit (hook?) to automatically add reviewers to > a patch according to the code sent? so in fact you'll have a place > somewhere for mapping code & specific developers? I really like this idea. Gerrit currently requires new users to know who to add as reviewers, IMHO impeding new contributors. One relative simple solution would be to look at who recently touched the files that are being modified and add them as reviewers. This can be done by looking at the git log for a file. Some pseudo python code solution: reviewers =3D set() for modified_file in commit.files: reviewers +=3D set(commit.author for commit in git.log(modified_file)) return reviewers This gives a system that those who touche a file, become the maintainer for that file. A more complex solution could improve on that and limit the reviewers added per patch. One can think of limiting to only contributions in the last X months, weigh contributions so common committers are prefered. It could also combine several methods. For example to limit to the 5 authors who touched the most files: reviewers =3D collections.Counter() # New in python 2.7 for modified_file in commit.files: reviewers +=3D collections.Counter(commit.author for commit in git.log(= modified_file)) return [author for author, count in reviewers.most_common(5)] Since Counter also accepts a dictionary, one could also weigh the touched lines per file. Downside there is big whitespace/formatting patches can skew the line count. In short, I think an entire thesis could be written on the optimal way to determine reviewers but a simple algorithm could do to show the method works. Does this help? --===============5467377934649383851==-- From iheim at redhat.com Tue Mar 11 11:11:29 2014 Content-Type: multipart/mixed; boundary="===============7855644248708293921==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 17:10:54 +0200 Message-ID: <531F277E.5010002@redhat.com> In-Reply-To: 20140311150600.GS5296@bogey.xentower.nl --===============7855644248708293921== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: > On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: >>> Tomasz Ko=C5=82ek wrote: >>> >>> I've got a few questions about project description. >>> Please tell me if my problem's understanding is good or not. >>> We need to add a few flags/methods to git review module. This flags sho= uld >>> allow to add potential reviewers in gerrit. >>> So: >>> Let's assume that we've got special flags for this operations. What's n= ext? >>> 1. In gerrit system we need to add special place for potential reviewer= s? >>> 2. Potential reviewers should agree that they want to review? >>> 3. We can have more than one accepted reviewer? >> >> I'm not sure i understood exactly what you mean by 'potential >> reviewers'. do want gerrit (hook?) to automatically add reviewers to >> a patch according to the code sent? so in fact you'll have a place >> somewhere for mapping code & specific developers? > > I really like this idea. Gerrit currently requires new users to know who > to add as reviewers, IMHO impeding new contributors. > > One relative simple solution would be to look at who recently touched > the files that are being modified and add them as reviewers. This can be > done by looking at the git log for a file. Some pseudo python code > solution: > > reviewers =3D set() > > for modified_file in commit.files: > reviewers +=3D set(commit.author for commit in git.log(modified_file= )) > > return reviewers > > This gives a system that those who touche a file, become the maintainer > for that file. A more complex solution could improve on that and limit > the reviewers added per patch. One can think of limiting to only > contributions in the last X months, weigh contributions so common > committers are prefered. It could also combine several methods. > > For example to limit to the 5 authors who touched the most files: > > reviewers =3D collections.Counter() # New in python 2.7 > > for modified_file in commit.files: > reviewers +=3D collections.Counter(commit.author for commit in git.l= og(modified_file)) > > return [author for author, count in reviewers.most_common(5)] > > Since Counter also accepts a dictionary, one could also weigh the > touched lines per file. Downside there is big whitespace/formatting > patches can skew the line count. > > In short, I think an entire thesis could be written on the optimal way > to determine reviewers but a simple algorithm could do to show the > method works. > > Does this help? > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > I think if we do this, we want to make sure we cover per file who is = required to +2 it before we consider it acked. --===============7855644248708293921==-- From eedri at redhat.com Tue Mar 11 11:14:45 2014 Content-Type: multipart/mixed; boundary="===============4127355810779255501==" MIME-Version: 1.0 From: Eyal Edri To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 11:14:26 -0400 Message-ID: <95289450.2052196.1394550866508.JavaMail.zimbra@redhat.com> In-Reply-To: 531F277E.5010002@redhat.com --===============4127355810779255501== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Itamar Heim" > To: "Eyal Edri" , "Tomasz Ko=C5=82ek" , users(a)ovirt.org, "infra" > Sent: Tuesday, March 11, 2014 5:10:54 PM > Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > = > On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: > > On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: > >>> Tomasz Ko=C5=82ek wrote: > >>> > >>> I've got a few questions about project description. > >>> Please tell me if my problem's understanding is good or not. > >>> We need to add a few flags/methods to git review module. This flags > >>> should > >>> allow to add potential reviewers in gerrit. > >>> So: > >>> Let's assume that we've got special flags for this operations. What's > >>> next? > >>> 1. In gerrit system we need to add special place for potential review= ers? > >>> 2. Potential reviewers should agree that they want to review? > >>> 3. We can have more than one accepted reviewer? > >> > >> I'm not sure i understood exactly what you mean by 'potential > >> reviewers'. do want gerrit (hook?) to automatically add reviewers to > >> a patch according to the code sent? so in fact you'll have a place > >> somewhere for mapping code & specific developers? > > > > I really like this idea. Gerrit currently requires new users to know who > > to add as reviewers, IMHO impeding new contributors. > > > > One relative simple solution would be to look at who recently touched > > the files that are being modified and add them as reviewers. This can be > > done by looking at the git log for a file. Some pseudo python code > > solution: > > > > reviewers =3D set() > > > > for modified_file in commit.files: > > reviewers +=3D set(commit.author for commit in git.log(modified_fi= le)) > > > > return reviewers > > > > This gives a system that those who touche a file, become the maintainer > > for that file. A more complex solution could improve on that and limit > > the reviewers added per patch. One can think of limiting to only > > contributions in the last X months, weigh contributions so common > > committers are prefered. It could also combine several methods. > > > > For example to limit to the 5 authors who touched the most files: > > > > reviewers =3D collections.Counter() # New in python 2.7 > > > > for modified_file in commit.files: > > reviewers +=3D collections.Counter(commit.author for commit in > > git.log(modified_file)) > > > > return [author for author, count in reviewers.most_common(5)] > > > > Since Counter also accepts a dictionary, one could also weigh the > > touched lines per file. Downside there is big whitespace/formatting > > patches can skew the line count. > > > > In short, I think an entire thesis could be written on the optimal way > > to determine reviewers but a simple algorithm could do to show the > > method works. > > > > Does this help? > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > = > I think if we do this, we want to make sure we cover per file who is > required to +2 it before we consider it acked. > = won't it require maintaining static lists of people per file/path/project?= =20 --===============4127355810779255501==-- From iheim at redhat.com Tue Mar 11 11:20:51 2014 Content-Type: multipart/mixed; boundary="===============6640661812622209975==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 17:20:29 +0200 Message-ID: <531F29BD.20206@redhat.com> In-Reply-To: 95289450.2052196.1394550866508.JavaMail.zimbra@redhat.com --===============6640661812622209975== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/11/2014 05:14 PM, Eyal Edri wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" , users(a)ovirt.org, "infra" >> Sent: Tuesday, March 11, 2014 5:10:54 PM >> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions >> >> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: >>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: >>>>> Tomasz Ko=C5=82ek wrote: >>>>> >>>>> I've got a few questions about project description. >>>>> Please tell me if my problem's understanding is good or not. >>>>> We need to add a few flags/methods to git review module. This flags >>>>> should >>>>> allow to add potential reviewers in gerrit. >>>>> So: >>>>> Let's assume that we've got special flags for this operations. What's >>>>> next? >>>>> 1. In gerrit system we need to add special place for potential review= ers? >>>>> 2. Potential reviewers should agree that they want to review? >>>>> 3. We can have more than one accepted reviewer? >>>> >>>> I'm not sure i understood exactly what you mean by 'potential >>>> reviewers'. do want gerrit (hook?) to automatically add reviewers to >>>> a patch according to the code sent? so in fact you'll have a place >>>> somewhere for mapping code & specific developers? >>> >>> I really like this idea. Gerrit currently requires new users to know who >>> to add as reviewers, IMHO impeding new contributors. >>> >>> One relative simple solution would be to look at who recently touched >>> the files that are being modified and add them as reviewers. This can be >>> done by looking at the git log for a file. Some pseudo python code >>> solution: >>> >>> reviewers =3D set() >>> >>> for modified_file in commit.files: >>> reviewers +=3D set(commit.author for commit in git.log(modified_f= ile)) >>> >>> return reviewers >>> >>> This gives a system that those who touche a file, become the maintainer >>> for that file. A more complex solution could improve on that and limit >>> the reviewers added per patch. One can think of limiting to only >>> contributions in the last X months, weigh contributions so common >>> committers are prefered. It could also combine several methods. >>> >>> For example to limit to the 5 authors who touched the most files: >>> >>> reviewers =3D collections.Counter() # New in python 2.7 >>> >>> for modified_file in commit.files: >>> reviewers +=3D collections.Counter(commit.author for commit in >>> git.log(modified_file)) >>> >>> return [author for author, count in reviewers.most_common(5)] >>> >>> Since Counter also accepts a dictionary, one could also weigh the >>> touched lines per file. Downside there is big whitespace/formatting >>> patches can skew the line count. >>> >>> In short, I think an entire thesis could be written on the optimal way >>> to determine reviewers but a simple algorithm could do to show the >>> method works. >>> >>> Does this help? >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> >> I think if we do this, we want to make sure we cover per file who is >> required to +2 it before we consider it acked. >> > > won't it require maintaining static lists of people per file/path/project? > yes, but considering our project layout, i don't see an alternative. (some of the layout could be improved to be path based, rather than file = based) --===============6640661812622209975==-- From didi at redhat.com Tue Mar 11 11:29:24 2014 Content-Type: multipart/mixed; boundary="===============8576662292752922684==" MIME-Version: 1.0 From: Yedidyah Bar David To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 11:29:09 -0400 Message-ID: <2078244652.17889448.1394551749290.JavaMail.zimbra@redhat.com> In-Reply-To: 531F29BD.20206@redhat.com --===============8576662292752922684== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Itamar Heim" > To: "Eyal Edri" > Cc: users(a)ovirt.org, "Tomasz Ko=C5=82ek" , "infra= " > Sent: Tuesday, March 11, 2014 5:20:29 PM > Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > = > On 03/11/2014 05:14 PM, Eyal Edri wrote: > > > > > > ----- Original Message ----- > >> From: "Itamar Heim" > >> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" , > >> users(a)ovirt.org, "infra" > >> Sent: Tuesday, March 11, 2014 5:10:54 PM > >> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > >> > >> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: > >>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: > >>>>> Tomasz Ko=C5=82ek wrote: > >>>>> > >>>>> I've got a few questions about project description. > >>>>> Please tell me if my problem's understanding is good or not. > >>>>> We need to add a few flags/methods to git review module. This flags > >>>>> should > >>>>> allow to add potential reviewers in gerrit. > >>>>> So: > >>>>> Let's assume that we've got special flags for this operations. What= 's > >>>>> next? > >>>>> 1. In gerrit system we need to add special place for potential > >>>>> reviewers? > >>>>> 2. Potential reviewers should agree that they want to review? > >>>>> 3. We can have more than one accepted reviewer? > >>>> > >>>> I'm not sure i understood exactly what you mean by 'potential > >>>> reviewers'. do want gerrit (hook?) to automatically add reviewers to > >>>> a patch according to the code sent? so in fact you'll have a place > >>>> somewhere for mapping code & specific developers? > >>> > >>> I really like this idea. Gerrit currently requires new users to know = who > >>> to add as reviewers, IMHO impeding new contributors. > >>> > >>> One relative simple solution would be to look at who recently touched > >>> the files that are being modified and add them as reviewers. This can= be > >>> done by looking at the git log for a file. Some pseudo python code > >>> solution: > >>> > >>> reviewers =3D set() > >>> > >>> for modified_file in commit.files: > >>> reviewers +=3D set(commit.author for commit in > >>> git.log(modified_file)) > >>> > >>> return reviewers > >>> > >>> This gives a system that those who touche a file, become the maintain= er > >>> for that file. A more complex solution could improve on that and limit > >>> the reviewers added per patch. One can think of limiting to only > >>> contributions in the last X months, weigh contributions so common > >>> committers are prefered. It could also combine several methods. > >>> > >>> For example to limit to the 5 authors who touched the most files: > >>> > >>> reviewers =3D collections.Counter() # New in python 2.7 > >>> > >>> for modified_file in commit.files: > >>> reviewers +=3D collections.Counter(commit.author for commit in > >>> git.log(modified_file)) > >>> > >>> return [author for author, count in reviewers.most_common(5)] > >>> > >>> Since Counter also accepts a dictionary, one could also weigh the > >>> touched lines per file. Downside there is big whitespace/formatting > >>> patches can skew the line count. > >>> > >>> In short, I think an entire thesis could be written on the optimal way > >>> to determine reviewers but a simple algorithm could do to show the > >>> method works. > >>> > >>> Does this help? > >>> _______________________________________________ > >>> Users mailing list > >>> Users(a)ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/users > >>> > >> > >> I think if we do this, we want to make sure we cover per file who is > >> required to +2 it before we consider it acked. > >> > > > > won't it require maintaining static lists of people per file/path/proje= ct? > > > = > yes, but considering our project layout, i don't see an alternative. > (some of the layout could be improved to be path based, rather than file > based) Extending Ewoud's idea, we can also check the list of people committing (rather than reviewing) changes to each file in the change. -- = Didi --===============8576662292752922684==-- From dcaroest at redhat.com Tue Mar 11 12:40:46 2014 Content-Type: multipart/mixed; boundary="===============6205056299971995388==" MIME-Version: 1.0 From: David Caro To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 17:40:02 +0100 Message-ID: <531F3C62.2010203@redhat.com> In-Reply-To: 95289450.2052196.1394550866508.JavaMail.zimbra@redhat.com --===============6205056299971995388== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8g2T7IQmS1E8OmSlnIBno6eqBl8hkAFtD Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: quoted-printable On Tue 11 Mar 2014 04:14:26 PM CET, Eyal Edri wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Eyal Edri" , "Tomasz Ko=3DC5=3D82ek" , users(a)ovirt.org, "infra" >> Sent: Tuesday, March 11, 2014 5:10:54 PM >> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - question= =3D s >> >> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: >>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: >>>>> Tomasz Ko=3DC5=3D82ek wrote: >>>>> >>>>> I've got a few questions about project description. >>>>> Please tell me if my problem's understanding is good or not. >>>>> We need to add a few flags/methods to git review module. This flags= =3D >>>>> should >>>>> allow to add potential reviewers in gerrit. >>>>> So: >>>>> Let's assume that we've got special flags for this operations. What= =3D 's >>>>> next? >>>>> 1. In gerrit system we need to add special place for potential revi= =3D ewers? >>>>> 2. Potential reviewers should agree that they want to review? >>>>> 3. We can have more than one accepted reviewer? >>>> >>>> I'm not sure i understood exactly what you mean by 'potential >>>> reviewers'. do want gerrit (hook?) to automatically add reviewers t= =3D o >>>> a patch according to the code sent? so in fact you'll have a place >>>> somewhere for mapping code & specific developers? >>> >>> I really like this idea. Gerrit currently requires new users to know = =3D who >>> to add as reviewers, IMHO impeding new contributors. >>> >>> One relative simple solution would be to look at who recently touched= =3D >>> the files that are being modified and add them as reviewers. This can= =3D be >>> done by looking at the git log for a file. Some pseudo python code >>> solution: >>> >>> reviewers =3D3D set() >>> >>> for modified_file in commit.files: >>> reviewers +=3D3D set(commit.author for commit in git.log(modified_= =3D file)) >>> >>> return reviewers >>> >>> This gives a system that those who touche a file, become the maintain= =3D er >>> for that file. A more complex solution could improve on that and limi= =3D t >>> the reviewers added per patch. One can think of limiting to only >>> contributions in the last X months, weigh contributions so common >>> committers are prefered. It could also combine several methods. >>> >>> For example to limit to the 5 authors who touched the most files: >>> >>> reviewers =3D3D collections.Counter() # New in python 2.7 >>> >>> for modified_file in commit.files: >>> reviewers +=3D3D collections.Counter(commit.author for commit in >>> git.log(modified_file)) >>> >>> return [author for author, count in reviewers.most_common(5)] >>> >>> Since Counter also accepts a dictionary, one could also weigh the >>> touched lines per file. Downside there is big whitespace/formatting >>> patches can skew the line count. >>> >>> In short, I think an entire thesis could be written on the optimal wa= =3D y >>> to determine reviewers but a simple algorithm could do to show the >>> method works. >>> >>> Does this help? >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> >> I think if we do this, we want to make sure we cover per file who is >> required to +2 it before we consider it acked. >> > > won't it require maintaining static lists of people per file/path/proje= =3D ct? > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra We already discussed that, in the project, and one of the solutions=3D20 proposed was to add metadata on each file/directory about the=3D20 maintainers for that file/directory. For what I've seen in other=3D20 projects (mainly openstack), they do that per repository, and not per=3D20 file, that simplifies the maintainers selection greatly (having it on=3D20 gerrit config so you don't have to check the code to decide who has=3D20 merge rights). But that might be another subject. About dynamically adding reviewers, it should be fairly easy to do=3D20 using a small gerrit hook to run on patch-submitted. But gerrit will=3D20 fail if the user is not already created in gerrit so not really=3D20 allowing non-registered users to get in. But I'm not sure if it's=3D20 'polite' to add someone as a reviewer if he did not previously agreed=3D20 to it, specially when emails will be sent to him. And as Ewoud says, selecting which commiters are considered possible=3D20 reviewers gives enough talk for a thesis by itself. -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --8g2T7IQmS1E8OmSlnIBno6eqBl8hkAFtD Content-Type: application/pgp-signature; name=3D"signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=3D"signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTHzxiAAoJEEBxx+HSYmnD2ZEH/1i8of7ywJaIwKKyxzgyYp2H AUlZRkqCbdZTkVrMSIFsXikuRnEVeJY0eXVd5G4mco2Qf7962+dpW2xjLctJL8T0 YaLXiQUR+TvpnBp5OvB0870hhKo9ql010KjijjediMceswENSV6fwciQn+zvdUfe MkCD6/I5aB4vwLGm7CUIB64lLeaSbYGoAUJYc3XkH+czKmSJce1D4JD3xCDufLLE NDu0jdcHizss0czsWzwG8k8twDE/MVgaLmd0xiU3Mvjg3pkQ6h7mUQMe7spRWpJM FOSI+MBek1q+mxtcbsuGpPvyT5WqyoKA6XzYWrWdclvCfzQiYhRJ1eQTjUIgKcE=3D =3D7A1Y -----END PGP SIGNATURE----- --8g2T7IQmS1E8OmSlnIBno6eqBl8hkAFtD-- --===============6205056299971995388== Content-Type: multipart/signed MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhbiBPcGVuUEdQL01JTUUgc2lnbmVkIG1lc3NhZ2UgKFJGQyA0ODgwIGFuZCAzMTU2 KQotLThnMlQ3SVFtUzFFOE9tU2xuSUJubzZlcUJsOGhrQUZ0RApDb250ZW50LVR5cGU6IHRleHQv cGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXBy aW50YWJsZQoKT24gVHVlIDExIE1hciAyMDE0IDA0OjE0OjI2IFBNIENFVCwgRXlhbCBFZHJpIHdy b3RlOgo+Cj4KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4+IEZyb206ICJJdGFtYXIg SGVpbSIgPGloZWltQHJlZGhhdC5jb20+Cj4+IFRvOiAiRXlhbCBFZHJpIiA8ZWVkcmlAcmVkaGF0 LmNvbT4sICJUb21hc3ogS289QzU9ODJlayIgPHRvbWFzei1rb2xla0A9Cm8yLnBsPiwgdXNlcnNA b3ZpcnQub3JnLCAiaW5mcmEiIDxpbmZyYUBvdmlydC5vcmc+Cj4+IFNlbnQ6IFR1ZXNkYXksIE1h cmNoIDExLCAyMDE0IDU6MTA6NTQgUE0KPj4gU3ViamVjdDogUmU6IFtVc2Vyc10gW0dTT0NdW0dl cnJpdF0gYWRkIHBvdGVudGlhbCByZXZpZXdlcnMgLSBxdWVzdGlvbj0Kcwo+Pgo+PiBPbiAwMy8x MS8yMDE0IDA1OjA2IFBNLCBFd291ZCBLb2hsIHZhbiBXaWpuZ2FhcmRlbiB3cm90ZToKPj4+IE9u IFR1ZSwgTWFyIDExLCAyMDE0IGF0IDEwOjM3OjIyQU0gLTA0MDAsIEV5YWwgRWRyaSB3cm90ZToK Pj4+Pj4gVG9tYXN6IEtvPUM1PTgyZWsgd3JvdGU6Cj4+Pj4+Cj4+Pj4+IEkndmUgZ290IGEgZmV3 IHF1ZXN0aW9ucyBhYm91dCBwcm9qZWN0IGRlc2NyaXB0aW9uLgo+Pj4+PiBQbGVhc2UgdGVsbCBt ZSBpZiBteSBwcm9ibGVtJ3MgdW5kZXJzdGFuZGluZyBpcyBnb29kIG9yIG5vdC4KPj4+Pj4gV2Ug bmVlZCB0byBhZGQgYSBmZXcgZmxhZ3MvbWV0aG9kcyB0byBnaXQgcmV2aWV3IG1vZHVsZS4gVGhp cyBmbGFncz0KCj4+Pj4+IHNob3VsZAo+Pj4+PiBhbGxvdyB0byBhZGQgcG90ZW50aWFsIHJldmll d2VycyBpbiBnZXJyaXQuCj4+Pj4+IFNvOgo+Pj4+PiBMZXQncyBhc3N1bWUgdGhhdCB3ZSd2ZSBn b3Qgc3BlY2lhbCBmbGFncyBmb3IgdGhpcyBvcGVyYXRpb25zLiBXaGF0PQoncwo+Pj4+PiBuZXh0 Pwo+Pj4+PiAxLiBJbiBnZXJyaXQgc3lzdGVtIHdlIG5lZWQgdG8gYWRkIHNwZWNpYWwgcGxhY2Ug Zm9yIHBvdGVudGlhbCByZXZpPQpld2Vycz8KPj4+Pj4gMi4gUG90ZW50aWFsIHJldmlld2VycyBz aG91bGQgYWdyZWUgdGhhdCB0aGV5IHdhbnQgdG8gcmV2aWV3Pwo+Pj4+PiAzLiBXZSBjYW4gaGF2 ZSBtb3JlIHRoYW4gb25lIGFjY2VwdGVkIHJldmlld2VyPwo+Pj4+Cj4+Pj4gSSdtIG5vdCBzdXJl IGkgdW5kZXJzdG9vZCBleGFjdGx5IHdoYXQgeW91IG1lYW4gYnkgJ3BvdGVudGlhbAo+Pj4+IHJl dmlld2VycycuICBkbyB3YW50IGdlcnJpdCAoaG9vaz8pIHRvIGF1dG9tYXRpY2FsbHkgYWRkIHJl dmlld2VycyB0PQpvCj4+Pj4gYSBwYXRjaCBhY2NvcmRpbmcgdG8gdGhlIGNvZGUgc2VudD8gIHNv IGluIGZhY3QgeW91J2xsIGhhdmUgYSBwbGFjZQo+Pj4+IHNvbWV3aGVyZSBmb3IgbWFwcGluZyBj b2RlICYgc3BlY2lmaWMgZGV2ZWxvcGVycz8KPj4+Cj4+PiBJIHJlYWxseSBsaWtlIHRoaXMgaWRl YS4gR2Vycml0IGN1cnJlbnRseSByZXF1aXJlcyBuZXcgdXNlcnMgdG8ga25vdyA9Cndobwo+Pj4g dG8gYWRkIGFzIHJldmlld2VycywgSU1ITyBpbXBlZGluZyBuZXcgY29udHJpYnV0b3JzLgo+Pj4K Pj4+IE9uZSByZWxhdGl2ZSBzaW1wbGUgc29sdXRpb24gd291bGQgYmUgdG8gbG9vayBhdCB3aG8g cmVjZW50bHkgdG91Y2hlZD0KCj4+PiB0aGUgZmlsZXMgdGhhdCBhcmUgYmVpbmcgbW9kaWZpZWQg YW5kIGFkZCB0aGVtIGFzIHJldmlld2Vycy4gVGhpcyBjYW49CiBiZQo+Pj4gZG9uZSBieSBsb29r aW5nIGF0IHRoZSBnaXQgbG9nIGZvciBhIGZpbGUuIFNvbWUgcHNldWRvIHB5dGhvbiBjb2RlCj4+ PiBzb2x1dGlvbjoKPj4+Cj4+PiByZXZpZXdlcnMgPTNEIHNldCgpCj4+Pgo+Pj4gZm9yIG1vZGlm aWVkX2ZpbGUgaW4gY29tbWl0LmZpbGVzOgo+Pj4gICAgICByZXZpZXdlcnMgKz0zRCBzZXQoY29t bWl0LmF1dGhvciBmb3IgY29tbWl0IGluIGdpdC5sb2cobW9kaWZpZWRfPQpmaWxlKSkKPj4+Cj4+ PiByZXR1cm4gcmV2aWV3ZXJzCj4+Pgo+Pj4gVGhpcyBnaXZlcyBhIHN5c3RlbSB0aGF0IHRob3Nl IHdobyB0b3VjaGUgYSBmaWxlLCBiZWNvbWUgdGhlIG1haW50YWluPQplcgo+Pj4gZm9yIHRoYXQg ZmlsZS4gQSBtb3JlIGNvbXBsZXggc29sdXRpb24gY291bGQgaW1wcm92ZSBvbiB0aGF0IGFuZCBs aW1pPQp0Cj4+PiB0aGUgcmV2aWV3ZXJzIGFkZGVkIHBlciBwYXRjaC4gT25lIGNhbiB0aGluayBv ZiBsaW1pdGluZyB0byBvbmx5Cj4+PiBjb250cmlidXRpb25zIGluIHRoZSBsYXN0IFggbW9udGhz LCB3ZWlnaCBjb250cmlidXRpb25zIHNvIGNvbW1vbgo+Pj4gY29tbWl0dGVycyBhcmUgcHJlZmVy ZWQuIEl0IGNvdWxkIGFsc28gY29tYmluZSBzZXZlcmFsIG1ldGhvZHMuCj4+Pgo+Pj4gRm9yIGV4 YW1wbGUgdG8gbGltaXQgdG8gdGhlIDUgYXV0aG9ycyB3aG8gdG91Y2hlZCB0aGUgbW9zdCBmaWxl czoKPj4+Cj4+PiByZXZpZXdlcnMgPTNEIGNvbGxlY3Rpb25zLkNvdW50ZXIoKSAgIyBOZXcgaW4g cHl0aG9uIDIuNwo+Pj4KPj4+IGZvciBtb2RpZmllZF9maWxlIGluIGNvbW1pdC5maWxlczoKPj4+ ICAgICAgcmV2aWV3ZXJzICs9M0QgY29sbGVjdGlvbnMuQ291bnRlcihjb21taXQuYXV0aG9yIGZv ciBjb21taXQgaW4KPj4+ICAgICAgZ2l0LmxvZyhtb2RpZmllZF9maWxlKSkKPj4+Cj4+PiByZXR1 cm4gW2F1dGhvciBmb3IgYXV0aG9yLCBjb3VudCBpbiByZXZpZXdlcnMubW9zdF9jb21tb24oNSld Cj4+Pgo+Pj4gU2luY2UgQ291bnRlciBhbHNvIGFjY2VwdHMgYSBkaWN0aW9uYXJ5LCBvbmUgY291 bGQgYWxzbyB3ZWlnaCB0aGUKPj4+IHRvdWNoZWQgbGluZXMgcGVyIGZpbGUuIERvd25zaWRlIHRo ZXJlIGlzIGJpZyB3aGl0ZXNwYWNlL2Zvcm1hdHRpbmcKPj4+IHBhdGNoZXMgY2FuIHNrZXcgdGhl IGxpbmUgY291bnQuCj4+Pgo+Pj4gSW4gc2hvcnQsIEkgdGhpbmsgYW4gZW50aXJlIHRoZXNpcyBj b3VsZCBiZSB3cml0dGVuIG9uIHRoZSBvcHRpbWFsIHdhPQp5Cj4+PiB0byBkZXRlcm1pbmUgcmV2 aWV3ZXJzIGJ1dCBhIHNpbXBsZSBhbGdvcml0aG0gY291bGQgZG8gdG8gc2hvdyB0aGUKPj4+IG1l dGhvZCB3b3Jrcy4KPj4+Cj4+PiBEb2VzIHRoaXMgaGVscD8KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+PiBVc2VycyBtYWlsaW5nIGxpc3QKPj4+ IFVzZXJzQG92aXJ0Lm9yZwo+Pj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3VzZXJzCj4+Pgo+Pgo+PiBJIHRoaW5rIGlmIHdlIGRvIHRoaXMsIHdlIHdhbnQgdG8gbWFr ZSBzdXJlIHdlIGNvdmVyIHBlciBmaWxlIHdobyBpcwo+PiByZXF1aXJlZCB0byArMiBpdCBiZWZv cmUgd2UgY29uc2lkZXIgaXQgYWNrZWQuCj4+Cj4KPiB3b24ndCBpdCByZXF1aXJlIG1haW50YWlu aW5nIHN0YXRpYyBsaXN0cyBvZiBwZW9wbGUgcGVyIGZpbGUvcGF0aC9wcm9qZT0KY3Q/Cj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBJbmZyYSBtYWls aW5nIGxpc3QKPiBJbmZyYUBvdmlydC5vcmcKPiBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxt YW4vbGlzdGluZm8vaW5mcmEKCldlIGFscmVhZHkgZGlzY3Vzc2VkIHRoYXQsIGluIHRoZSBwcm9q ZWN0LCBhbmQgb25lIG9mIHRoZSBzb2x1dGlvbnM9MjAKcHJvcG9zZWQgd2FzIHRvIGFkZCBtZXRh ZGF0YSBvbiBlYWNoIGZpbGUvZGlyZWN0b3J5IGFib3V0IHRoZT0yMAptYWludGFpbmVycyBmb3Ig dGhhdCBmaWxlL2RpcmVjdG9yeS4gRm9yIHdoYXQgSSd2ZSBzZWVuIGluIG90aGVyPTIwCnByb2pl Y3RzIChtYWlubHkgb3BlbnN0YWNrKSwgdGhleSBkbyB0aGF0IHBlciByZXBvc2l0b3J5LCBhbmQg bm90IHBlcj0yMApmaWxlLCB0aGF0IHNpbXBsaWZpZXMgdGhlIG1haW50YWluZXJzIHNlbGVjdGlv biBncmVhdGx5IChoYXZpbmcgaXQgb249MjAKZ2Vycml0IGNvbmZpZyBzbyB5b3UgZG9uJ3QgaGF2 ZSB0byBjaGVjayB0aGUgY29kZSB0byBkZWNpZGUgd2hvIGhhcz0yMAptZXJnZSByaWdodHMpLgoK QnV0IHRoYXQgbWlnaHQgYmUgYW5vdGhlciBzdWJqZWN0LgoKQWJvdXQgZHluYW1pY2FsbHkgYWRk aW5nIHJldmlld2VycywgaXQgc2hvdWxkIGJlIGZhaXJseSBlYXN5IHRvIGRvPTIwCnVzaW5nIGEg c21hbGwgZ2Vycml0IGhvb2sgdG8gcnVuIG9uIHBhdGNoLXN1Ym1pdHRlZC4gQnV0IGdlcnJpdCB3 aWxsPTIwCmZhaWwgaWYgdGhlIHVzZXIgaXMgbm90IGFscmVhZHkgY3JlYXRlZCBpbiBnZXJyaXQg c28gbm90IHJlYWxseT0yMAphbGxvd2luZyBub24tcmVnaXN0ZXJlZCB1c2VycyB0byBnZXQgaW4u IEJ1dCBJJ20gbm90IHN1cmUgaWYgaXQncz0yMAoncG9saXRlJyB0byBhZGQgc29tZW9uZSBhcyBh IHJldmlld2VyIGlmIGhlIGRpZCBub3QgcHJldmlvdXNseSBhZ3JlZWQ9MjAKdG8gaXQsIHNwZWNp YWxseSB3aGVuIGVtYWlscyB3aWxsIGJlIHNlbnQgdG8gaGltLgoKQW5kIGFzIEV3b3VkIHNheXMs IHNlbGVjdGluZyB3aGljaCBjb21taXRlcnMgYXJlIGNvbnNpZGVyZWQgcG9zc2libGU9MjAKcmV2 aWV3ZXJzIGdpdmVzIGVub3VnaCB0YWxrIGZvciBhIHRoZXNpcyBieSBpdHNlbGYuCgotLQpEYXZp ZCBDYXJvCgpSZWQgSGF0IFMuTC4KQ29udGludW91cyBJbnRlZ3JhdGlvbiBFbmdpbmVlciAtIEVN RUEgRU5HIFZpcnR1YWxpemF0aW9uIFImRAoKRW1haWw6IGRjYXJvQHJlZGhhdC5jb20KV2ViOiB3 d3cucmVkaGF0LmNvbQpSSFQgR2xvYmFsICM6IDgyLTYyNjA1CgoKLS04ZzJUN0lRbVMxRThPbVNs bklCbm82ZXFCbDhoa0FGdEQKQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9wZ3Atc2lnbmF0dXJl OyBuYW1lPSJzaWduYXR1cmUuYXNjIgpDb250ZW50LURlc2NyaXB0aW9uOiBPcGVuUEdQIGRpZ2l0 YWwgc2lnbmF0dXJlCkNvbnRlbnQtRGlzcG9zaXRpb246IGF0dGFjaG1lbnQ7IGZpbGVuYW1lPSJz aWduYXR1cmUuYXNjIgoKLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251 UEcgdjEKCmlRRWNCQUVCQWdBR0JRSlRIenhpQUFvSkVFQnh4K0hTWW1uRDJaRUgvMWk4b2Y3eXdK YUl3S0t5eHpneVlwMkgKQVVsWlJrcUNiZFpUa1ZyTVNJRnNYaWt1Um5FVmVKWTBlWFZkNUc0bWNv MlFmNzk2MitkcFcyeGpMY3RKTDhUMApZYUxYaVFVUitUdnBuQnA1T3ZCMDg3MGhoS285cWwwMTBL amlqamVkaU1jZXN3RU5TVjZmd2NpUW4renZkVWZlCk1rQ0Q2L0k1YUI0dndMR203Q1VJQjY0bExl YVNiWUdvQVVKWWMzWGtIK2N6S21TSmNlMUQ0SkQzeENEdWZMTEUKTkR1MGpkY0hpenNzMGN6c1d6 d0c4azh0d0RFL01WZ2FMbWQweGlVM012amczcGtRNmg3bVVRTWU3c3BSV3BKTQpGT1NJK01CZWsx cStteHRjYnN1R3BQdnlUNVdxeW9LQTZYellXcldkY2x2Q2Z6UWlZaFJKMWVRVGpVSWdLY0U9Cj03 QTFZCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQoKLS04ZzJUN0lRbVMxRThPbVNsbklCbm82 ZXFCbDhoa0FGdEQtLQo= --===============6205056299971995388==-- From mlipchuk at redhat.com Tue Mar 11 15:40:19 2014 Content-Type: multipart/mixed; boundary="===============7285067779541833994==" MIME-Version: 1.0 From: Maor Lipchuk To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 21:39:36 +0200 Message-ID: <531F6678.5070104@redhat.com> In-Reply-To: 1756612588.2041647.1394549604045.JavaMail.zimbra@redhat.com --===============7285067779541833994== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Tomasz, I'm very please to hear that you are interested in the GSOC project, see my answers inline. It's great to see that you know the material pretty well, I'm interested to hear some more ideas and feedbacks. I will start a thread soon (Maybe also schedule a call) once getting more feedbacks from other contributors, so we can brain storm some more and get practical with it. If you have any more questions, please don't hesitate to ask me. thanks, Maor On 03/11/2014 04:53 PM, Meital Bourvine wrote: > Eyal, > = > I think that he's asking about [1]. > = > As far as I understand, the idea is to automatically get the reviewers na= mes, with commands like `git blame`, or from gerrit - get previous reviewer= s to the same file/module... > = > Adding Maor, since he might have some additional info. > = > [1] http://www.ovirt.org/Summer_of_Code#Idea:_Gerrit_add_potential_review= ers > = > ----- Original Message ----- >> From: "Eyal Edri" >> To: "Tomasz Ko=C5=82ek" >> Cc: users(a)ovirt.org, "infra" >> Sent: Tuesday, March 11, 2014 4:37:22 PM >> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions >> >> >> >> ----- Original Message ----- >>> From: "Tomasz Ko=C5=82ek" >>> To: users(a)ovirt.org >>> Sent: Monday, March 10, 2014 9:56:28 PM >>> Subject: [Users] [GSOC][Gerrit] add potential reviewers - questions >>> >>> >>> >>> Hi >>> >>> I'd like to contribute (within GSOC) in idea: Gerrit add potential >>> reviewers. >>> >>> Maybe at first I=E2=80=99ll introduce myself. >>> I'm Tomek, student from Poland. I study Computer Science at University = of >>> Wroclaw. The next year will be last year of my first degree study, I ho= pe. >>> As a python programmer I'm working since one year at Nokia Solutions and >>> Networks (don't worry I intend to change my job to another or to >>> participation at GSOC). Every day at work and school I'm using version >>> control system (Git and SVN). At work we were using to Gerrit as a revi= ew >>> system but currently we're using JIRA to report review statuses. >>> I love spend my free time in mountains (mainly polish - Tatras mountain= s). >>> That's all about me. >>> >>> I've got a few questions about project description. >>> Please tell me if my problem's understanding is good or not. >>> We need to add a few flags/methods to git review module. This flags sho= uld >>> allow to add potential reviewers in gerrit. >>> So: >>> Let's assume that we've got special flags for this operations. What's n= ext? >>> 1. In gerrit system we need to add special place for potential reviewer= s? Adding a plugin to gerrit is an interesting idea although it will require the administrator to add it in the server, and I want that the operation will be more available to any submitter in any project. I think that we can address it in a later phase though. >>> 2. Potential reviewers should agree that they want to review? no, since gerrit does not question the reviewer if he wants to be added or not I think we should keep this behaviour as well. although as I see it, the operation of adding the reviewers, will not be completely automatic for the submitter, we should let the submitter of the patch to choose which reviewers he wants to add, very similar to the screen being used when doing a rebase in git. (see attached file add_reviewers.png) >>> 3. We can have more than one accepted reviewer? Yes, that is correct. >> >> Hi Tomasz, >> I'm not sure i understood exactly what you mean by 'potential reviewers'. >> do want gerrit (hook?) to automatically add reviewers to a patch accordi= ng to >> the code sent? >> so in fact you'll have a place somewhere for mapping code & specific >> developers? >> >> cause if you mean by adding reviewers to a patch, that's easily done by = just >> clicking the '+' sign on each patch. >> those reviewers should have logged in at least once to gerrit.ovirt.org = in >> order to be in the list of potential viewers, >> and they don't require any special permissions to review with +1/-1 any = patch >> sent. >> you can add as many reviewers as you want to a patch. >> >> does that answer your question? >> >> Eyal. >> >> >> >>> >>> I know above questions might seem chaotic but I think answers allow me = to >>> better understanding Yours needments >>> >>> Best regards >>> Tomasz Kolek >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> --===============7285067779541833994== Content-Type: image/png MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="add_reviewers.png" iVBORw0KGgoAAAANSUhEUgAABaAAAAOECAIAAADYLwGFAAAAA3NCSVQICAjb4U/gAAAAGXRFWHRT b2Z0d2FyZQBnbm9tZS1zY3JlZW5zaG907wO/PgAAIABJREFUeJzs3XlYVNX/B/DPDMMWCAwzoLil kGKJCmoKCOaWZYKioICpg5iiZolZqbl/00zLzFCTFEUxQEAlpczUr6QIau76dRdyCWNfBIRh+/1x +Y0jzL3MHQYG9P16enoun3vmnM8958w8zpm7CBwcHAgAAAAAAAAAoFmKiYlRp5iosfMAAHgJxceH q4x7eQU0aR4AAAAAAC8NIa/SbP9kZ4urUyHzn3ar1biGhreoWXNN3G4zUXf0OWYCxzzRulopNbzp ZjK+jZ1Gs/0caBrNLU8npx47d/5QNyu2OAAAAABAS6fjMziYHzPxU+dLS80h5p4njUqHTb88XozP geaW54QJY9et23LlynU14wAAAAAALR0uUVGXqanJ5MnjnJ37CIXC5ORz27btlsvLdZtSfHx4c/tO BdbWUj8/LycnBzOzVo8fZ8TEHDhx4rSukwLVzMxaTZzo3adPTzMzs8LCwvPnr+zevbew8AkprbY0 n7cY3/d7+/Y216/fVj8OAAAAANBSlJaWXrh0zrGn0yuvmCjH+V2i8tISiUQrVnwul5fPmbNk9uyF 1taSceNG6TopaHasraWrVi1MS3vw+edf+vvP2LRpx5AhbrpOClh9+unM8vKK+fNX+vvPmD9/ZXl5 xaefzmR2eXkFNJ+lDc0YGxtVVFSoHwcAAAAAaBFKy0qTU05mZ2edSkl6+rREedezMzgGDnT28xtj ZSW5efNOSEhYZmY2ERkY6Mtkvm5u/QQCwd69vyoKs8XZxMeHnzp1tlev7gkJR+zt7bp2tYuIiP39 9+Mc5ZmNWt8x4uPDt2+P8vHxqK6uTko6Gx4eXV5e8y91N7f+o0e/2769TVFR8Z498UePnmTiLi59 J03ykUolDx/+s3Hj9rS0B1Tnt9C6P4127Nj+ww8DNmzYlp7+LxG9++7ggoLCbdt+ZvaGhUUuXjz3 55/3Mq8ND9/j4fF2q1amkZH7fvnldyISCoXe3iOHDRtoampy9uzF0NCI0tJS7n5TmSfbuNS9eUe9 X8ZU9o+RkeGUKX7Ozn2IKCXl/I4dUWVlcuI/XsrJNPBr4fDhgyZO9CYiZnzrPU2GrX9U5q/BuPAy YcLY3347dvDgH8yfN27cWb78W2ab7/iuWbOxbnmRSCSTjR840FkgEMTGHpw6dQLT21o8Ll7zhK1+ tnz44vgcUNk/fNvt2tXu669DSkqeElF2dm5k5L6wsO+0mKeXV8D8+bMjIuKys3M6dGg3e3Zg584d OeqxtX114kSfLl06Gxsb3b//KC4uISXlHLG/39k+x2qVV5Rhi3Mcl8rP23XrVkRExF66dI2IDAz0 w8LWz579RUFBIXdtAAAAAABakZKSVFRcJBAInj4tST6dNHTwcMWuZ2dwuLj0Xbly/cSJsy5f/t/M mTImOH78KCsrSXDwkuDgJT16dFMUZotzOHz4+KpVG/z8vOLjf//Pf74bO3YkR2GOn08dHLrNmbMk OHiJlZXE29uDCY4cOWz8eM/t2yOnTJmzYsW33bp1UZR3d++/bNk3kyfPPnv2YlDQZHVSfeONrrNn T/nmm83M6gYRDRjQLyHhCBH17t1j584ffH1HS6WWivKOjt2XLl0zbdo8J6ceTMTTc3iPHq8vWbIm KOizysqq998fy8Q5+o0tT5XjougfZqPeLyps/ePvP0YstggOXhIcvFQqtfTz81K8hNd4aVHfvr3m zFkyZ85iqdRSndNkVPYPseSvwbjw0qtX9+Tkv1Tu4jW+bOV9fDzatm3zySfLPv54kYPDszy1dVx8 5wlb/Wz58MUxt1X2D992T58+7+8/RiKx1NPTk0gs/fy8UlLOazfPkyfPrFjx2a5dG/v1cwoN3cVd z4IFHyUmnpo27dMJE2Zu2xY5ePCAWvWr+X6vVb7eOAeVn7dHjiQOH/4Ws923r+Pt26lY3QAAAACA JvOk6ImpaatBA4eYmZkVFxcr73q2wLFmzcb09H/LyuQJCUfeeMOeCbq7O4eHR+flFeTm5u/YEa0o zBbncOPGndu37xHR9eu37t5Nk0jEmh1MeHh0Xl5+Xl5BeHj0W2+5MMFRo94JCQm7ceNOaWnZo0eP N27crigfFhaVlZVTWloWH3+I++dTRv/+vT/5ZMaqVRuys3MVwY4d292//5CIAgL8QkK2nzhxWk9P T7H3xx93pqdnFBY+Wb78GyYyfPigzZvDMzOzi4qKIyJimZ++ibPf2PJUOS58sfWPi0tfJp+8vPwd O6JcXd9UvESD8dLKWf3K4ztwoHO95dn6R2X+GowLL2Zmpnl5+Sp38R1fleUHDXINC4vMycnLzy/c uXOPorC2jovvPGGrny0fLVLZP3zb/emniG7duoSFfbd3b1hY2HfdunXZunW3dvOcOtXfykpiZGTo 5TVCcdoOm+rq6g4d2tnZvWpiYnLz5p2vvtqg3WQ0oPLz9s8/U3r2fMPc3IyI3nrLJTExWac5AgAA AMDLxcTE1NXZrVUrM+b/yrtqLlGxs3t18uTxdnadTE2fu0WHWGyRlZXDbCs2OOIcFNeSMBvKCwS8 KLer+NYtlVo+ePCPyvI5OTXrFGVlckNDg3rrHzVqeElJiZOTg/K/2o2NjZhbD9rYtL506ZpA8NxL mMsKlFlZWW7ZslbxZ3V1NbPB0W8q82QbF77Y+qdWPmKxhWKXtsaLr+fzMecuzNE/KvPXYFx4KSws EostMjKy6u7iO74qy1tairOysuvmqa3j4jtP2Opny0eLVPYP33bnzJl2+/a9tWs35uUViMXmY8e+ N2fOtNWrf9BinhJJzalehoYGzHU9HL788jsvrxEffPB+u3ZtSkvLQkMjTp06q8VkNKDy8/bp09LT p88PGTLgyJETb7zR9bvvtuguQQAAAAB46Qwd/DazYWBgOPitocq7ahY4Pvvsw7i4hLVrNxUXl5ia muzevYmJ5+XlW1lJ0tMziEgqlShexhbXjFwuNzDQV/OhJIp2rawkeXkFTDA7O7dDh3Z376ap36Li +4byxSZEtGLFd2Kx+cqVC+7e/fvRo3QmWFLy1NJSnJGR9fhxhqOjg1D43ApH3e9RmZnZCxasKioq rhXn229s46JoVyAQqPPtka1/8vMLlPPJzy+ot6rGpjy+OTl5yrvqzhPu/qlLW+PC5vLl/7m6vrl/ /29qluebf25uXuvWVo8ePSYiKyupIq6t4+I7T9jqZ8uHG6/PAZX4tuvo6BAYGFxcXEJEWVk5u3fv DQtbr3HrDac4a0ZPT8/V9c2goEnKCxx13+8cn2PaovLzlogOH06cO3d6cfHTc+cu17twAwAAAADQ NGouUTE0NCgoKCwrk1tbS4OCJil2nzhxWibztbAwE4stAgJ8641rJi3t4ZAhbkKhWo90kcl8xWJz CwszmcxX8QDOgwf/mD070N7+NUNDg7Zt28yYIeOuJC3twejR7xoZGVpZSQID/ZV3yeXyjIysH37Y Nm/eDMUvw2lpD7p2tSWi8PDojz4KHDCgH3f9hw8nzp4d2KaNtb6+yN7+tUWLgpk4335jGxdGbm5e nz696vZbfHy44m6CDLb+SU7+i+lPsdg8IMCXuaOhxuq2qwHl8f3zzxTlXXXnCXf/1KWtcWETFbXf w2OYp+dwqdRSX1/UpYvt0qWfcJTnm39iYnJg4ASJxNLc3GzSpHFaPy6+84StfrZ8uPH6HFCJb7t3 76ZOnOhtZSXR09OzspJMnOh9506qxq033PLln/Xu3dPIyEhfX2RkZFhrpabu+53jc0wDKt+/Kj9v iejOnVS5vHzChLFsN50BAAAAAGh6NWdwbNiwLTDQf/782Tk5eRERce7uNfc+iI09IJP5btiwUigU xsUl9OvnxB3XzNatu4ODpwUFTRYIBNxPASCimzfvhIR8VVVVlZR0Njb2ABNMSDhSWPhk+vSJ7dq1 KSoqiY6O525xy5Zds2cHjhs3KisrOyIiVvneE4yrV28cPpwYFDT5hx+2EVFiYrKPj2dy8rkLF67K ZB8T0fr1oRz1M3ckXbx4rrW19OHD9Li4mjz59hvbuDDCw2NmzJgskYgV/caRj8r+iYqKnzrVf8OG lUR05syFqKh6+q0JXL9+OyTkq8rKyqSks3v3JijvqjtPuPunLm2NC5uMjKwvvljt7z/G29ujVSuT x48zYmIOcJTnm39cXIJMNn79+hVEFB0d36+fo3aPi+88YaufLR9uvD4H2PLn1e633/44adK4r79e bG7eqqDgycWL19at+1G5RTWb5psnmwMHDnt7v7dw4cdlZWW3bt37+uuNynvrvt/r/RxrOJWft4w/ /kgMCPC9fPm61hsFAAAAANCMwMHBQdc58FD3ea5NQyAQLFs2r7KyateumIcP06uqqpo+hxeP+s+4 1aFmm6REIl69etH06Z/qOhFQje1spuY2kThwf966uzu7u/dvDndCBQAAAIAXXkxMjDrFRI2dx4uh urr6q682jB07cuHCj5kbMc6bt7wxbp34UmkR3/SaW5Jz5wbFxPySn1/o5+d15swFXacDLyl9fdG7 7w46dixJ14kAAAAAADyDBQ51yeXl0dHx9V78AtCoLl68+uWXC0QivXPnLkdG7tN1OsCquS2NaVds 7LZr124q35UDAAAAAEDnWtglKgAAAAAAAADwUlG+REUul99/8LCwsNDCwqJjh/b6+vqKXfweWMB2 Vbmaz85wcuqxc+cPDX/QhtbVukfgy4Z5ekLdY2cbL5URvo9Q0eAlKitpyMu1pZmkwRff92Ojzocm wJZ/s/1cAgAAAACAWuTl5X+dv5CZlVVaVvZvRsbZc+flcrlib5NeojJhwth167ZcuYK77jc7Kk+n ZxuvuoVrPfNC/RbxrVKH+L4fG3U+NAG2/PG5BAAAAADQUqSl/V0rkpr2dzf7rsx2ky5wtG9vc/36 7QZWYmpqMnnyOGfnPkKhMDn53LZtu+Xycq2kpzFdPdulsWllvLTF2lrq5+fl5ORgZtaKefzqS3v9 v7bmG9/xbVbzgfj3A1v+ze24AAAAAACATU5ubq1Ibl6eYpvfJSoNZGxsVFFR0ZAaRCLRihWfy+Xl c+YsmT17obW1ZNy4UdpKD2pp+Hhpi7W1dNWqhWlpDz7//Et//xmbNu0YMsRN10m1eHzHt/nMB82w 5d/SjwsAAAAA4OVR92GmypFnZ3AMHOjs5zfGykpy8+adkJCwzMxsIjIw0JfJfN3c+gkEgr17f1UU ZouzqXWTC8XvrkZGhlOm+Dk79yGilJTzO3ZElZXJOeLvvju4oKBw27afmZeHhUUuXjz355/3MjWH h+/x8Hi7VSvTyMh9v/zyOxEJhUJv75HDhg00NTU5e/ZiaGhEaWkpd/4uLn0nTfKRSiUPH/6zceP2 tLQHHP1T9+Yd9f6k7ObWf/Tod9u3tykqKt6zJ/7o0ZMcxxsfH37q1NlevbonJByxt7fr2tUuIiL2 99+Pq9PbDfmRn2281D9MBlv/8zVhwtjffjt28OAfzJ83btxZvvxbZpvveK1Zs7FueZFIJJONHzjQ WSAQxMYenDp1AnOAGswfldjGkW3cbW1fnTjRp0uXzsbGRvfvP4qLS0hJOUf85xvHvFKup97R1NV8 4NsPtc7pUPxZb/7q98P27VE+Ph7V1dVJSWfDw6PLyyuIaN26FRERsZcuXSMiAwP9sLD1s2d/UVBQ WF9/AAAAAACANj1b4HBx6bty5fqcnFxPz+EzZ8pWrFhHROPHj7KykgQHLxEIBLNmBSgKs8XZqPz6 QUT+/mPEYovg4CVEgg8/nOLn57VzZwxHfMCAfrGxB4mod+8ec+ZMu3r1hlRqqajN0bH70qVriopK PvlkBrPA4ek5vEeP15csWVNS8jQgwO/998eGhUVy5+/u3n/Zsm+ePCkaPfrdoKDJCxas5OgftuNi M3LksHfeGfTjjzvT0h5IpZZeXiOYBQ624yWiw4ePJyQcXb36i2XLviktLZs3b0a9CxwNx3ZcfO+t wNb/fPXq1T0qar/KXbzGi628j49H27ZtPvlkWWVl5cyZzw5Zg/nDRuU4so37ggUf7d4dt3btpqqq Sju7zmPGjGC+2POdb2z1861HV/NBW/1Qb/7qrwY6OHSbM2cJUfXMmQHe3h7Mc6OPHEkcPvwtZoGj b1/H27dTsboBAAAAAND0nl2ismbNxvT0f8vK5AkJR954w54Jurs7h4dH5+UV5Obm79gRrSjMFufL xaUvU09eXv6OHVGurm9yxzt2bHf//kMiCgjwCwnZfuLEaT09PUVtP/64Mz09o7DwyfLl3zCR4cMH bd4cnpmZXVRUHBERy/yUzZ1/WFhUVlZOaWlZfPyhzp07cvcPX6NGvRMSEnbjxp3S0rJHjx5v3Lid +3iJ6MaNO7dv3yOi69dv3b2bJpGI623FyyugmdwThK3/+TIzM83Ly1e5i+94qSw/aJBrWFhkTk5e fn7hzp176s1fg/mvchzZxr26urpDh3Z2dq+amJjcvHnnq682qN9XyjjmlU7wnQ/a6gctCg+PzsvL z8srCA+PfustFyb4558pPXu+YW5uRkRvveWSmJis0xwBAAAAAF5SNWdw2Nm9OnnyeDu7TqamJsq7 xWKLrKwcZluxwRHnq1Y9YrEFd9zY2Kiw8AkR2di0vnTpmkDwXG3MZQjKrKwst2xZq/hTcXEOR/45 OTX3LCkrkxsaGjDbbP3Dl1Rq+eDBP3XjbMdLRMw58IoN5QWd5o+t//kqLCwSiy0yMrLq7uI7XirL W1qKs7JqJo/yfNBg/rBROY5s4/7ll995eY344IP327VrU1paFhoacerUWXVaqYVjXukE3/mgrX7Q IuX+VKw2Pn1aevr0+SFDBhw5cuKNN7p+990W3SUIAAAAAPDyqlng+OyzD+PiEtau3VRcXGJqarJ7 9yYmnpeXb2UlSU/PICKpVKJ4GVucr/z8AuV68vMLuOMlJU8tLcUZGVmPH2c4OjoIhc+tcNT9vpSZ mb1gwaqiouJacb75s/WPol2BQKDOt/fs7NwOHdrdvZtWK852vC2LXC43MNBXfqgNW//zdfny/1xd 39y//zc1y3OPV125uXmtW1s9evSYiKyspIq4tuYPG7ZxV5zdo6en5+r6ZlDQJOUv9urPN93Oq4bP B779IJfLDQ0NmPuMKF+8pkWK/rSykuTlPevPw4cT586dXlz89Ny5y0wCAAAAAADQxGouUTE0NCgo KCwrk1tbS4OCJil2nzhxWibztbAwE4stAgJ8643zlZz8l0zmKxabi8XmAQG+zAX2HPG0tAddu9oS UXh49EcfBQ4Y0I+7/sOHE2fPDmzTxlpfX2Rv/9qiRcGa5c/WP4zc3Lw+fXoJhbUfSRMfH17r9gQH D/4xe3agvf1rhoYGbdu2mTFDxn28mqnbbtNIS3s4ZIibcj+w9T9fUVH7PTyGeXoOl0ot9fVFXbrY Ll36CUd57vGqKzExOTBwgkRiaW5uNmnSuHrzb+z5v3z5Z7179zQyMtLXFxkZGdZaEWCbb+rX3zQa Ph/49kNa2oPRo981MjK0spIEBvo3MH+V7yOmPy0szGQyX+UHFd+5kyqXl0+YMDY5+a8GtgsAAAAA AJqpOYNjw4ZtgYH+8+fPzsnJi4iIc3d3ZuKxsQdkMt8NG1YKhcK4uIR+/Zy443xFRcVPneq/YcNK Ijpz5kJUVDx3PDEx2cfHMzn53IULV2Wyj4lo/fpQjvoTEo4Q0eLFc62tpQ8fpsfFHdAsf7b+YYSH x8yYMVkiEQsEAu6bXyQkHCksfDJ9+sR27doUFZUwdyjkON7mhvupE1u37g4OnhYUNFnRD2z9z1dG RtYXX6z29x/j7e3RqpXJ48cZMTFcVXGPV11xcQky2fj161cQUXR0fL9+jkxcW/OHDdu4Hzhw2Nv7 vYULPy4rK7t1697XX29UfpX6862x51Vjzwe+/bBly67ZswPHjRuVlZUdERHbGPccuXnzTkjIV1VV VUlJZ2Njn8v/jz8SAwJ8L1++rvVGAQAAAABAHQIHBwdd58CDQCBYtmxeZWXVrl0xDx+mV1VV6Tqj FwHfh3223EbVIZGIV69eNH36p7pOBJod7uetuLs7u7v3bw53QgUAAAAAeMHExNQ8ZvRUyum6ewe4 1PykLaq7rzmrrq7+6qsNY8eOXLjwY+aGnfPmLdf41pXA0MkSQ3Nb15g7Nygm5pf8/EI/P68zZy7o Oh1oYfT1Re++O+jYsSRdJwIAAAAA8PJqYQscRCSXl0dHxysu7gDQiosXr3755QKRSO/cucuRkft0 nQ60MLGx265du6l8Vw4AAAAAAGhiLewSFQAAAAAAAAB4qah5iUr9D2JQxvZsDjWf2eHk1GPnzh90 8oAPbrXulfiyYZ4WoXzsHAPdlI9oqZVSw5tuJuPb2GloXD93JzeT3quXtvJk+7xSGdHJo4t01S4A AAAAQPPUpJeoTJgwdt26LVeu4CkDzY6ad8RgiunkC5UOm355cHdyc7ttChtt5cn2eVW3fl1NTrwp AAAAAACUNekCR/v2Ntev325gJaamJpMnj3N27iMUCpOTz23btlsuL9dKehrjfrYC6IS1tdTPz8vJ ycHMrBXzWFncH6E5Y3uqjg6ftqOVzysAAAAAAGgy/C5RaSBjY6OKioqG1CASiVas+FwuL58zZ8ns 2QutrSXjxo3SVnrwwrC2lq5atTAt7cHnn3/p7z9j06YdQ4a46Top4OLlFaByCYMt3gQa/nkFAAAA AABN6dkZHAMHOvv5jbGykty8eSckJCwzM5uIDAz0ZTJfN7d+AoFg795fFYXZ4mxq3eRC8Y3FyMhw yhQ/Z+c+RJSScn7HjqiyMjlH/N13BxcUFG7b9jPz8rCwyMWL5/78816m5vDwPR4eb7dqZRoZue+X X34nIqFQ6O09ctiwgaamJmfPXgwNjSgtLeXO38Wl76RJPlKp5OHDfzZu3J6W9oCjf+revKPeL2Nu bv1Hj363fXuboqLiPXvijx49yXG88fHhp06d7dWre0LCEXt7u65d7SIiYn///bg6vd3Ar4XDhw+a ONGbiJKSzoaHR9d7mgxb/6jMX4Nx4WXChLG//Xbs4ME/mD9v3LizfPm3zDbf8V2zZmPd8iKRSCYb P3Cgs0AgiI09OHXqBKa3tXhcvOYJW/1s+fDFcXqFyv7RVruNnWe99dR6K/E9nYRvP8ydG1RaWvrj jzuJaNasAAMDg++//4k0/RwAAAAAAHjZPDuDw8Wl78qV6ydOnHX58v9mzpQxwfHjR1lZSYKDlwQH L+nRo5uiMFucjeJn2Fq/x/r7jxGLLYKDlwQHL5VKLf38vLjjAwb0S0g4QkS9e/fYufMHX9/RUqml ojZHx+5Ll66ZNm2ek1MPJuLpObxHj9eXLFkTFPRZZWXV+++PrTd/d/f+y5Z9M3ny7LNnLwYFTebu n1rHVe/XnpEjh40f77l9e+SUKXNWrPi2W7cu3MdLRIcPH1+1aoOfn1d8/O//+c93Y8eOrLe3taJv 315z5iyZM2exVGqpzmkyKvuHWPLXYFx46dWre3LyXyp38RpftvI+Ph5t27b55JNlH3+8yMHhWZ7a Oi6+84StfrZ8+OKY2yr7R1vtNnae9dZTq0K+p5Pw7YfQ0F2Ojg7Ozn1cXPr06tU9NHSXYpeuPgcA AAAAAFqQZwsca9ZsTE//t6xMnpBw5I037Jmgu7tzeHh0Xl5Bbm7+jh3RisJscb5cXPoy9eTl5e/Y EeXq+iZ3vGPHdvfvPySigAC/kJDtJ06c1tPTU9T2448709MzCgufLF/+DRMZPnzQ5s3hmZnZRUXF ERGxzE/f3PmHhUVlZeWUlpbFxx/q3Lkjd//wNWrUOyEhYTdu3CktLXv06PHGjdu5j5eIbty4c/v2 PSK6fv3W3btpEom43la0clZ/eHh0Xl5+Xl5BeHj0wIHO9ZZn6x+V+WswLryYmZnm5eWr3MV3fFWW HzTINSwsMicnLz+/cOfOPYrC2jouvvOErX62fLRIZf80Qbt8sY17o+LbDyUlT7/7bsvMmbIZM2Tr 1m15+vTZ6R4afA4AAAAAALxsai5RsbN7dfLk8XZ2nUxNTZR3i8UWWVk5zLZigyPOV616xGIL7rix sVFh4RMisrFpfenSNYHgudqYywqUWVlZbtmyVvFndXV1vfnn5OQyG2VlckNDA2abrX/4kkotHzz4 p26c7XiJqLy8QnlDeUGnUT2fjzl3YY7+UZm/BuPCS2FhkVhskZGRVXcX3/FVWd7SUpyVlV03T20d F995wlY/Wz5apLJ/mqBdvlTm2dg06Idbt+79+28WUTWznKGgq88BAAAAAIAWpGaB47PPPoyLS1i7 dlNxcYmpqcnu3ZuYeF5evpWVJD09g4ikUoniZWxxvvLzC5Tryc8v4I6XlDy1tBRnZGQ9fpzh6Ogg FD63wlH3+0NmZvaCBauKioprxfnmz9Y/inYFAoE6316ys3M7dGh3925arTjb8eqQIh8rK0lOTp7y LrlcbmCgr3xXDu7+qUtb48Lm8uX/ubq+uX//b2qW55t/bm5e69ZWjx49JiIrK6kirq3j4jtP2Opn y4db3fHlS7N2W7q6/aZBP7z1louxsRERDRzorOZzfxo+XgAAAAAAL4aaS1QMDQ0KCgrLyuTW1tKg oEmK3SdOnJbJfC0szMRii4AA33rjfCUn/yWT+YrF5mKxeUCAb0rKOe54WtqDrl1tiSg8PPqjjwIH DOjHXf/hw4mzZwe2aWOtry+yt39t0aJgzfJn6x9Gbm5enz69hMLaj6SJjw9X3JWQcfDgH7NnB9rb v2ZoaNC2bZsZM2Tcx6uZuu1qgMnHwsJMJvP9888U5V1paQ+HDHFTPl7u/qlLW+PCJipqv4fHME/P 4VKppb6+qEsX26VLP+Eozzf/xMTkwMAJEomlubnZpEnjtH5cfOcJW/1s+XCrO758adZuS1e337j7 oe771MLCLDDQPyRkW0hIWGDgBHNCl3GzAAAgAElEQVRzM83aBQAAAAB4OdWcwbFhw7bAQP/582fn 5ORFRMS5u9fccyE29oBM5rthw0qhUBgXl9CvnxN3nK+oqPipU/03bFhJRGfOXIiKiueOJyYm+/h4 Jiefu3Dhqkz2MRGtXx/KUT9zR9LFi+daW0sfPkyPizugWf5s/cMID4+ZMWOyRCIWCATcN79ISDhS WPhk+vSJ7dq1KSoqiY6u53h16Pr12yEhX1VWViYlnd27N0F519atu4ODpwUFTVYcL3f/1KWtcWGT kZH1xRer/f3HeHt7tGpl8vhxRkzMAY7yfPOPi0uQycavX7+CiKKj4/v1c9TucfGdJ2z1s+XDre74 sj1VhCN/vu3W++ASdZrmmydf3PXX7Te+/RAUNPnYsZN37qQR0fHjSUFBk9auredkIpXtAgAAAAC8 nAQODg66zoEHgUCwbNm8ysqqXbtiHj5Mr6qq0nVGLwK+D7/UiWabpEQiXr160fTpn+o6EQAAAAAA gBdTTEwMs3EqRcV13ANcan6ibmELHERkYKA/duzIQYNcmRsxzpu3vDncwhBeNnPnBsXE/JKfXxgQ 4FtaWhYWFqnrjAAAAAAAAF5Mai5wiJouIy2Ry8ujo+MVJ+0D6MTFi1e//HKBSKR37tzlyMh9uk4H AAAAAADgZdfyFjgAmoPExOTExGRdZwEAAAAAAAA1+N14n+3ZHGo+s8PJqcfOnT80/AEfWlfr3oEv G+ZpDnWPnW28VEb4PrpFg5eorKQhL9eWZpIGX3zfj406H5phu+rTVbsAAAAAAKCsSc/gmDBh7Lp1 W65cud6UjYI6VN65k2286hau9awN9VvEd0Id4vt+bNT50AzbVR8mMwAAAABAc9CkCxzt29tcv367 gZWYmppMnjzO2bmPUChMTj63bdtuubxcK+lpLD4+vLk92kMrtDJe2mJtLfXz83JycjAza8U89vXE CRV3l3kZaGu+8R1fXc2HZjUPAQAAAACg2eJ3iUoDGRsbVVRUNKQGkUi0YsXncnn5nDlLZs9eaG0t GTdulLbSg1oaPl7aYm0tXbVqYVrag88//9Lff8amTTuGDHHTdVItHt/x1dV8aD7zEAAAAAAAmrNn Z3AMHOjs5zfGykpy8+adkJCwzMxsIjIw0JfJfN3c+gkEgr17f1UUZouzqXWTC8Xvz0ZGhlOm+Dk7 9yGilJTzO3ZElZXJOeLvvju4oKBw27afmZeHhUUuXjz355/3MjWHh+/x8Hi7VSvTyMh9v/zyOxEJ hUJv75HDhg00NTU5e/ZiaGhEaWkpd/4uLn0nTfKRSiUPH/6zceP2tLQHHP1T9+Yd9f607ubWf/To d9u3tykqKt6zJ/7o0ZMcxxsfH37q1NlevbonJByxt7fr2tUuIiL299+Pq9PbDfmRn2281D9MBlv/ 8zVhwtjffjt28OAfzJ83btxZvvxbZpvveK1Zs7FueZFIJJONHzjQWSAQxMYenDp1AnOAGswfldjG kW3cbW1fnTjRp0uXzsbGRvfvP4qLS0hJOUf85xvHvFKup97R1NV80FW7c+cGlZaW/vjjTiKaNSvA wMDg++9/Ik3fjwAAAAAA0DSencHh4tJ35cr1EyfOunz5fzNnypjg+PGjrKwkwcFLgoOX9OjRTVGY Lc7GyyuA+Sqi2GD4+48Riy2Cg5cEBy+VSi39/Ly44wMG9EtIOEJEvXv32LnzB1/f0VKppaI2R8fu S5eumTZtnpNTDybi6Tm8R4/XlyxZExT0WWVl1fvvj603f3f3/suWfTN58uyzZy8GBU3m7p9ax1Xv 162RI4eNH++5fXvklClzVqz4tlu3LtzHS0SHDx9ftWqDn59XfPzv//nPd2PHjqy3txuObbzUOUZl bP3PV69e3ZOT/1K5i9d4sZX38fFo27bNJ58s+/jjRQ4Oz+aDBvOHjcpxZBv3BQs+Skw8NW3apxMm zNy2LXLw4AFMnO98Y6ufbXzZ6Go+6Krd0NBdjo4Ozs59XFz69OrVPTR0l2KXTt6PAAAAAACgjmcL HGvWbExP/7esTJ6QcOSNN+yZoLu7c3h4dF5eQW5u/o4d0YrCbHG+XFz6MvXk5eXv2BHl6vomd7xj x3b37z8kooAAv5CQ7SdOnNbT01PU9uOPO9PTMwoLnyxf/g0TGT580ObN4ZmZ2UVFxRERscxP2dz5 h4VFZWXllJaWxccf6ty5I3f/8DVq1DshIWE3btwpLS179Ojxxo3buY+XiG7cuHP79j0iun791t27 aRKJuN5W+H79azxs/c+XmZlpXl6+yl18x0tl+UGDXMPCInNy8vLzC3fu3FNv/hrMf5XjyDbu1dXV HTq0s7N71cTE5ObNO199tUH9vlLGMa90QlvzobHbLSl5+t13W2bOlM2YIVu3bsvTp89O99Dg/QgA AAAAAE2j5hIVO7tXJ08eb2fXydTURHm3WGyRlZXDbCs2OOJ81apHLLbgjhsbGxUWPiEiG5vWly5d Ewieq425DEGZlZXlli1rFX9WV1fXm39OTi6zUVYmNzQ0YLbZ+ocvqdTywYN/6sbZjpeIyssrlDeU F3SaP7b+56uwsEgstsjIyKq7i+94qSxvaSnOyqqZPMrzQYP5w0blOLKN+5dffuflNeKDD95v165N aWlZaGjEqVNn1WmlFo55pRPamg9N0O6tW/f+/TeLqJpZzlBo0e9HAAAAAIAXW80Cx2effRgXl7B2 7abi4hJTU5Pduzcx8by8fCsrSXp6BhFJpRLFy9jifOXnFyjXk59fwB0vKXlqaSnOyMh6/DjD0dFB KHxuhaPu95bMzOwFC1YVFRXXivPNn61/FO0KBAJ1vjVlZ+d26NDu7t20WnG2421Z5HK5gYG+8kNt 2Pqfr8uX/+fq+ub+/b+pWZ57vOrKzc1r3drq0aPHRGRlJVXEtTV/2LCNu+LsHj09PVfXN4OCJikv cKg/33Q7rxpvPjRBu2+95WJsbEREAwc6q/m8nrrtAgAAAABAU6q5RMXQ0KCgoLCsTG5tLQ0KmqTY feLEaZnM18LCTCy2CAjwrTfOV3LyXzKZr1hsLhabBwT4MndS5IinpT3o2tWWiMLDoz/6KHDAgH7c 9R8+nDh7dmCbNtb6+iJ7+9cWLQrWLH+2/mHk5ub16dNLKKz9SJr4+HDF3RAZBw/+MXt2oL39a4aG Bm3btpkxQ8Z9vJqp227TSEt7OGSIm3I/sPU/X1FR+z08hnl6DpdKLfX1RV262C5d+glHee7xqisx MTkwcIJEYmlubjZp0rh682/s+b98+We9e/c0MjLS1xcZGRnW+mbONt/Ur79pNN580G67dd8vFhZm gYH+ISHbQkLCAgMnmJubadYuAAAAAAA0pZozODZs2BYY6D9//uycnLyIiDh3d2cmHht7QCbz3bBh pVAojItL6NfPiTvOV1RU/NSp/hs2rCSiM2cuREXFc8cTE5N9fDyTk89duHBVJvuYiNavD+Won7kj 6eLFc62tpQ8fpsfFHdAsf7b+YYSHx8yYMVkiEQsEAu6bXyQkHCksfDJ9+sR27doUFZVER9dzvM0N 99M3tm7dHRw8LShosqIf2Pqfr4yMrC++WO3vP8bb26NVK5PHjzNiYriq4h6vuuLiEmSy8evXryCi 6Oj4fv0cmbi25g8btnE/cOCwt/d7Cxd+XFZWduvWva+/3qj8KvXnW2PPK13Nh8ZuNyho8rFjJ+/c SSOi48eTgoImrV1bz0lAKtsFAAAAAICmJHBwcNB1DjwIBIJly+ZVVlbt2hXz8GF6VVWVrjN6EfB9 6GbLbVQdEol49epF06d/qutEAAAAAAAAgIgoJiaG2TiVouL68QEuNT9pt7AFDiIyMNAfO3bkoEGu zA07581b3mS3KoQX2Ny5QTExv+TnFwYE+JaWloWFReo6IwAAAAAAACBSe4FD1HQZaYlcXh4dHa+4 uANAKy5evPrllwtEIr1z5y5HRu7TdToAAAAAAADAT8tb4ABoDImJyYmJybrOAgAAAAAAADSEG/4D AAAAAAAAQIuHBQ4AAAAAAAAAaPGwwAEAAAAAAAAALR4WOAAAAAAAAACgxcMCBwAAAAAAAAC0eFjg AAAAAAAAAIAWDwscAAAAAAAAANDiYYEDAAAAAAAAAFo8LHAAAAAAAAAAQIuHBQ4AAAAAAAAAaPGw wAEAAAAAAAAALR4WOAAAAAAAAACgxcMCBwAAAAAAAAC0eFjgAAAAAAAAAIAWDwscAAAAAAAAANDi NdECR1DCoaCEQ03TFnBjGwu+cQAAAAAAAIDmA2dwAAAAAAAAAECLJ9LsZYqf9KsqKkrycu+fPXsm fHv506faS0w7Wr/+Rk+vMe16OeqJRE+ysu7+mXhlX1yFXK7ylIRQjxFM+faOTnr6+k8LCx5fu3Yp Nib3/t+KMi4fTOvpNZYprPzauvHuIz16jvE2lUqLsrOv7N/7v18TSKnfarXL97jEHTu+OXFymzfe MDRtVVb05N/r1//avSvvwQO2ON/6+barrePixrTSkGpf1PkAAAAAAAAAzxY4RIaGsqiYv3aFZ929 O+rrtfvnBWfeusX94lCPEfpGxr19/RzHjRcZGiR+v76Rs+XN9YPpVw/En9wYUlle7uA5qp8sQNK5 85HVq5S/Q9q5Dxw2f2Hhv/8y5a8d/OXk5o3lT592dnEd+tn8tj177p48kSn5xoiRzLfWWurG7dwH us388PZ/j6Vs+8nlg+luMz8sLSy8d/IEW7t8jVi2olXrNodWLPvn0sV2jk4jlq2Q2tlFTp3CFteg CV7tauu4GtuLOh8AAAAAAADg2QJHe6feIgODv8+c7j7Sozg7O/P2bXVeX1769GJcjOO48R37vklE QpGo3yTZa4MH6+mJUpOTUrZtrSgrUxR+6+NgWzf3nLTUo2tWl+TmMsHuHp59/PyFIv3MmzdP/rjx SUYGEUk6de4fEGhl31XfyDj73r3Le2PTUpLrrb+u/fOCFdvXDh7oJwto18vxuRICQW9ffyK6GLtH ubxQJKqUy4noyb8ZTKRD7z4DZsy8/d9jXYcMVa5AZbz7SA8iuvpLfGlh4dVf4rsOGfrGeyPvnTzB 1i5fxTk5rVq3oerq6upqgUBAREVZ2RxxE4lk6OcLJJ1tU5NOKtfDN85WP9/jEopE/WUBrw0aQkR3 E/97Zmd4VUUF/f8ZDbePHX21X/+Kcnly6JbUU0n0/JkOyudxsNXD5kWdDwAAAAAAACAiorY9enqu XsP87b91O7MRdPA3XqfK6+kbEJGjz/he3j5//vB9hVw+9NPP5SUlZ3ZsV5TJSU3NTr3nNmNWf9mU 4+vXMUFJp85xH31o0aGj51dfu8388NDypUT09qLF5jZt4z+bl3XntrhDR6fxvswCB3f93LoMGUJE 5yN/Vg526u9s2alTUVbm7WNHFUHF1+nUU0nH131DRJavdhq24Iu7fyYmrl+n/MWVLS7pbEtEhY/T J2zfGffRLCKS2trV2676Dn6xYFDwJyOW/4f58+6fiUx/ssX7BwTadHdI2rJZIHzurit842z18z0u R5/xPcd4J23ZTERuM2aVFRdfiI5S7H148cL13w95fbPOdVoQs8DBTMW6l6hw18PtRZoPAAAAAAAA ICSi9KtXfvJ8T15cfD4qMmbWDCL6dckiNVc39I2MnXzGE1Fq8iki6jp0KBGlnkr6+3QKEdm5DVQu fPfkn8yv1u0cnRTBExt/KMnLe3z1ChG17vZ6TbWGRkTk6O3T2cW1KCvz6JrVTJy7fg4d+vYdMH3G ncTjVw/EK8d7+zE/m8co//If6jFix3jvm38cth3g1mfCRCIasXzF36dTEtevq66uVn45W1z/lVeI qLy0VCCgitJSItI3Nq63XfU5+ozrMmjwpb2xO8Z7X96397W3Bjn6jOOIt+3Vi4junTxx78SfyvXw jbPVz/e4mHG8d/IEMx+6Dh2mvDftVFLmzRtEZCKVcvcDdz0cXrD5AAAAAAAAADW/z0tsbQ1MTB5f u2rj4FBVWfnvjevqvDgo4VBg3D7HceNTTyWd3BRCRKYSKRFN2RM3NW4/EZlaWSmXlxcVyYuKiMjY 3JyJtHN0Grv+h8C4fdMP/kZEhiYmTPzYt2tzUlM7ObsMm79wUkSk/bC3mTh3/WxsB7i9u3jZg3N/ JX7/nXK8Y983rV7rUpyTc+vIH7VeIi8p+StiJxF1e+cdIjK1su46ZOj0g78pfsxnNtji5SUlRKRv ZPTzFJnIyIiIlO/AytGumnqM9iKiS7Ex8pIS5qIGJsIWNzYzJyJ5UVHZkyfK9fCNs9XP97iYcVTM BxPJcwsZleXltRYINKuHzYs3HwAAAAAAAEBESmfge6yqOVFiatz+gwvnp1+9wv3iUI8Rhqam7yxe 2tl1QNsePR9dvFCck2NmY7PD10deXFy3vIGpKbPxtLCA2Rg8d56JRHJg/mfZ9+4Fxu0jgYCJp1+5 HPfxh0bm5q+/M6LfZJnz1A9uHT1CRNz1q2Q/7O23Pg5OS0k+9s2aWj+P9/abQESX9sZWlpfXfWGF XE5E1ZWV9PxlEcoXSrDFc9JSbRx6mNnYZN+7Z9bGhoiyU++p2a46mKyUVVVUcsRLCwtfsbQ0MDUV /H8PM/jG2epnqH9czDgq5kNxTjZ3eS3W80LOBwAAAAAAABASUajHiJzU1DuJx7ePG1tVUXFy88ZQ jxH1rm4wyoqKTu8Iq66sHBT8iaGp6a1jR4mot6+/vrGxuGPHwZ98qlzYzs3dzs2diP65dKmmeT0h EclLSroMHqJc8r3lX1p16SovLv7n8kUiKn9aysS566+rx2ivQXPm3j3x59E1q2t9m23n6NS6W7eS vLwbvz+7gaXHqq/bOTrpGxkbmJg4T5lKRPdOnqxdqRqYh4D2GOVl1Mqsx6jRRHT9t1852mUEJRxS +dzQuvHUU6eIyHHceINXXunt60dEqadOcsTTr1wmpv/dn7uoh2+crX7u46rr9vFjpDQf7vz3WL0v IaKn+XlEZG7TVuN6WtZ8AAAAAAAAAPWJiMhUaiWxtb2wJ6pDn75Ckej+mdO8qsi8dStl+7YB02e4 zZp9/LtvBQLqOmSYg+eo/H8eXdwTrVzSqkuXzq5uGTdvnN0VzkRObt7kOm36qDXfMPeSVLiWcKB/ QGDr11+vrqzMuHH99I4wJn4pLoaj/rpcpwURUZdBg7sMGqwIbh3tUVVZ2cdvAhFd3hvHPB2DcSE6 0tFnXJs3ugsEgieZmX9F7Ly0N45XbzDunTxhZGbWc4z3pN2RRVlZST9uUjwyQ2W7fJ3evq386VM7 d/ceo7xKcnMuxcacj/qZI34mfEerNm36yabUeioK3zhb/XyP62LMHoNXTPr4TyCiK/H7L8bGqHPU Z3ft7Pv+JN+ftgkEAubMCL71vKjzAQAAAAAAAAQODg66zgEAAAAAAAAAQLWYmJofs0+lqDghY4CL M7MhrLsPAAAAAAAAAKBlwQIHAAAAAAAAALR4WOAAAAAAAAAAgBYPCxwAAAAAAAAA0OJhgQMAAAAA AAAAWjwscAAAAAAAAABAi/dsgUNkaDh13y89vcbYOPQISjhkbW+vw7QAAAAAAAAAANT3bIGjvVNv kYHB32dOd3J2Ls7Ozrx9W4dpAQAAAAAAAACoT0REbXv09Fy9hvnbf+t2ZiPo4G+hHiN0lhcAAAAA AAAAgNqERJR+9cpPnu/Ji4vPR0XGzJpBRL8uWYTVDQAAAAAAAABoKWouUZHY2hqYmDy+dtXGwaGq svLfG9d1mxYAAAAAAAAAgPpERBSUcIj5w2PVamZjatz+gwvnp1+9orO8AAAAAAAAAADUJiSiUI8R OampdxKPbx83tqqi4uTmjaEeI7C6AQAAAAAAAAAthZCITKVWElvbv1OSO/TpKxSJ7p85reusAAAA AAAAAAB4EBFRUXaW4paiuLcoAAAAAAAAALQ4Ql0nAAAAAAAAAADQUFjgAAAAAAAAAIAWDwscAAAA AAAAANDivYALHEEJhxQPvgUAAAAAAACAl8ELuMABAAAAAAAAAC8bkcavNGvTprffhPaOTsYWFkVZ WRf2RN06ekSLmQEAAAAAAAAAqOnZGRwiQ8Op+37p6TXGxqFHUMIha3t7jpeZ27Qd+31Ix75vntgU ssNv3KEVy9o7OjV+tgAAAAAAAAAAKjw7g6O9U2+RgcHfZ053H+lRnJ2defs2x8v6TpxkaGqa+P36 B3+dJaL8Rw+PfbuWiIQiUX9ZwGuDhhDR3cT/ntkZXlVREZRw6P7ZMzbdHSrKyh5eON/e0Unf2Pjc z7tdpwepjF89EE9E3T08+/j5C0X6mTdvnvxx45OMDCJibq5x+9jRV/v1ryiXJ4duST2VREQmEsnQ zxdIOtumJp1UzlPSqXP/gEAr+676RsbZ9+5d3hublpKs2MvUFuoxQmvdCQAAAAAAAAC6ICSitj16 BiUcemfxUiLy37q9p9dYE6k06OBvHC9r16sXET26eL5W3NFnfM8x3hf2RF3YE9VzjLejzzgm/mq/ /gmLFr5iaWk/7O3DK/9jYGLSy9uHI05Ekk6d4z768I+vVnbo29dt5ofKrTy8eOHQf5abWEpcpwUx kf4BgTbdHc7uCs/5O0255NuLFnfo2/f3/6zYPm7syU0hdgPf0rSjAAAAAAAAAKD5EhJR+tUrP3m+ Jy8uPh8VGTNrBhH9umQR93kNhq3MiOhpQUGteNehQ4no3skT906eIKKuQ4cpdmXdu6u88YpYzB0/ sfGHkry8x1evEFHrbq8rt5J2Kinz5g0iMpFKmUjbXr1q2j3xp3JJfUMjInL09uns4lqUlXl0zWrl vaEeI3D6BgAAAAAAAMALoOYSFYmtrYGJyeNrV20cHKoqK/+9cZ37ZWVPCo0txMbm5sU5OcpxU4mU iORFRcyfJhLps33V1cobAqGQI97O0am/bIpFh/b6RsZEZGhiotxKZXl5rXyMzcyV21U49u1a1w+m d3J26eTsUllefnJTCO6ECgAAAAAAAPDiERJRUMIh7w0bichj1Wr3WbOFenpT4/a37dGT42X/XL5M RO2deteKM+sdBqamBqamRFSck61ZWoPnzrPq0uXQsqXbfcYSEQkE3OVLCwuZdg1btVKOp1+5HPfx hzvf9zu7a6eevr7z1A80ywcAAAAAAAAAmjMhEYV6jMhJTb2TeHz7uLFVFRUnN28M9RiRfvUKx8vO /by7rKiof8CUDn376hsZW3bqNOTTz4no9vFjRGTn5m7n5k5Ed/57TMO09IREJC8p6TJ4iDrl069c rmnXfaBy/L3lX1p16SovLv7n8kUiKn9aqrw3KOEQc59RAAAAAAAAAGjRRERkKrWS2Npe2BPVoU9f oUh0/8zpel9WkP7Pvrkf9/Gb8NZHwcbm5kVZWRf2RBHRxZg9Bq+Y9PGfQERX4vdfjI3RLK2Tmze5 Tps+as03zENS6nUmfEerNm36yabUeorKtYQD/QMCW7/+enVlZcaN66d3hGmWDwAAAAAAAAA0ZwIH Bwdd5wAAAAAAAAAAoFpMTM3JE6dSVJyQMcDFmdkQ1t0HAAAAAAAAANCyYIEDAAAAAAAAAFo8LHAA AAAAAAAAQIvXghc42J6BoqtnozSffPB0GAAAAAAAAHjZtOAFDgAAAAAAAAAAhkjXCYD2hXqM0HUK AAAAAAAAAE3q2RkcIkPDqft+6ek1xsahR1DCIWt7ex2mBQAAAAAAAACgvmdncLR36i0yMPj7zOnu Iz2Ks7Mzb9/WrMbuHp59/PyFIv3MmzdP/rjxSUaGFusxkUiGfr5A0tk2NemkcmG2uBY1dj7MXTNu /nHYdoCbgYkJcxaGUCTqN0n22uDBenqi1OSklG1bK8rKiMh/63ZTK6vt48YSUWDsvidZmdHTpioq YSifx6Gynsm7Ix9duvTfb9cqig399PN2jo67Jk5ga5ctTwAAAAAAAADdEhFR2x49PVevYf7237qd 2Qg6+Jtm310lnTrHffShRYeOnl997Tbzw0PLl2qWmcp6+gcE2nR3SNqyWSB87u4hbHE2Ku/ByX28 jZqPQnV1dYRsYtfBQ5g/HX3G9/L2+fOH7yvk8qGffi4vKTmzYzsRPTj/l4PHKOlrXQQCEopED8+d Uz6Eukensp7s1FRxhw7KxcSvvpqdmsrRLlueAAAAAAAAALolJKL0q1d+8nxPXlx8PioyZtYMIvp1 ySKNf5k/sfGHkry8x1evEFHrbq9rnJnKetr26kVE906euHfiT+XCbHEtapp8/orYVVFaev3Qb8yf XYcOJaLUU0l/n04hIju3gUz84fnzTBpMJg/Pn+OuVmU9OampFu3ak0AwcefuiTt3CwQCi3btc1JT OdplyxMAAAAAAABAt2ouUZHY2hqYmDy+dtXGwaGqsvLfG9c1q66do1N/2RSLDu31jYyJyNDERLv1 GJuZE5G8qKhWebY4G77LN42dj8LTgnzlP00lUiKasieu5k8rK2Yj/crlyvLyNq+/TgJBpVyefuUy d7Uq68lJvScyMrLp3t2oVSsisunRU8/AICf1Hke7bHkCAAAAAAAA6JaIlK5o8Fi1mtmYGrf/4ML5 6Vev8K1u8Nx5JhLJgfmfZd+7Fxi3jwQCzdJiq6e0sPAVS0sDU1PB8zWzxdnwvUSlsfN5prpa+a/i nBwzG5sdvj7y4mLleEVZ2eNrV1t3e50Egsf/u1Yhl3PXqrIe5mqUbsPfzbh1UyAQdBv+jiLI1i5b ngAAAAAAAAC6JSSiUI8ROampdxKPbx83tqqi4uTmjaEeIzRY3SAioZ6QiOQlJV1U3Z0hKOGQypUF 9ethTlWwc3O3cx+oTlxbdJXPrWNHiai3r7++sbG4Y8fBn3yq2PXw/LlXLC1fEYsfnPtLs3oK/nlU UVZmO8At/eqV9CtXbF0HVJSVFfzziLtdAAAAAAAAgGZIRESmUiuJre2FPVEd+vQVikT3z5zWuLqT mze5Tps+as03qaeSau0SiiVj90QAACAASURBVEREVP70aUPqORO+o1WbNv1kU2o9nYQtzobvJSqN nQ+bS3ExAgF1HTLMwXNU/j+PLu6JVux6cO6cywfT6f/vx8FQXj9itpkjVVlPdXV17t9/W9vbp1+5 IhAI+kx4P/PWrerqau52AQAAAAAAAJohgYODQ9O01GXwkMFz5/3+n+XqnHEAAAAAAAAAAEBEMTEx zMapFBUnZAxwcWY2+D3EtCEcPEclbw3F6gYAAAAAAAAAaJ2oyVra/0lwk7UFAAAAAAAAAC+VpjuD AwAAAAAAAACgkWCBAwAAAAAAAABaPCxwAAAAAAAAAECLhwUOAAAAAAAAAGjxni1wiAwNp+77pafX GBuHHkEJh6zt7XWYFgAAAAAAAACA+p4tcLR36i0yMPj7zOlOzs7F2dmZt2/rMC0AAAAAAAAAAPWJ iKhtj56eq9cwf/tv3c5sBB38LdRjhM7yAgAAAAAAAABQm5CI0q9e+cnzPXlx8fmoyJhZM4jo1yWL sLoBAAAAAAAAAC1FzSUqEltbAxOTx9eu2jg4VFVW/nvjum7TAgAAAAAAAABQn4iIghIOMX94rFrN bEyN239w4fz0q1d0lhcAAAAAAAAAgNqERBTqMSInNfVO4vHt48ZWVVSc3Lwx1GMEVjcAAAAAAAAA oKUQEpGp1Epia/t3SnKHPn2FItH9M6d1nRUAAAAAAAAAAA8iIirKzlLcUhT3FgUAAAAAAACAFkeo 6wQAAAAAAAAAABoKCxwAAAAAAAAA0OJhgQMAAAAAAAAAWjyRdqtjnjjbxDfyUDzmlq1pnWTVqF6k I2rsY2mM+l+k/m8p1O/ztj17uc2YZd62rVAkwhgpw7wFAAAAgBeblhc4dIL597ryMgcAvLRcp00X d+y4Z8b0/EcPdZ0LAAAAAAA0HQ0XOOquJjTnXwWbc27Q/OF3b+1q7P40b9eeiAr+edRI9bNpieci NaRdvC8AAAAAoLl5dg8OkaHh1H2/9PQaY+PQIyjhkLW9PcfLQj1GKD9ZFv/GBYBmQmRgQETV1dW6 TgQAAAAAAJrUszM42jv1FhkY/H3mdPeRHsXZ2Zm3b2tc6aDgTzr1d64sL0/eGnrv5AkiEopE/SbJ Xhs8WE9PlJqclLJta0VZGRFJOnXuHxBoZd9V38g4+969y3tj01KSOcrzxXZ7DiZ++9jRV/v1ryiX J4duST2VpEGeHLoOGdrTa6x527YleXnnoyNvHzvKxLt7ePbx8xeK9DNv3jz548YnGRkc+XB76+Ng Wzf3nLTUo2tWl+TmcuRfbxfd/OOw7QA3AxMTppf41iMUifrLAl4bNISI7ib+98zO8KqKCo76TSSS oZ8vkHS2TU06WasetnZ55clWv3JV6qzKKc+fuq9Sf577/bTNvG27cP/xAoFA9nN0/j+P9syYzt20 ynnCtx/YsJUf/sXizq4D/gzZQERvfTQnLSX5j1Vfctevcp4r91Xd7br9qdk41sUxXmz9VnfeBiUc un/2jE13h4qysocXzrd3dNI3Nj738+6rB+L5tsv2vqhJ5vDvtm7uuffvH/36q+LcHA2Oi+N9x0Hl 5wZHnnXb5ZWPBv0JAAAAAKAZERG17dHTc/Ua5m//rduZjaCDv2l8XsajSxdvHP7d65t1Lh9MZ774 OfqM7+Xt8+cP31fI5UM//VxeUnJmx3YienvRYnObtvGfzcu6c1vcoaPTeF9m4YCtPF/ct+d4ePHC 9d8PeX2zznVaELOgwDdPNq+/8+7Aj+Y8PHfu0PKlVVWV/SbJFAsckk6d4z760KJDR8+vvnab+eGh 5Us58uGWk5qanXrPbcas/rIpx9ev48i/XtXV1RGyiV0HD2H+5FuPo8/4nmO8k7ZsJiK3GbPKiosv REdx1N8/INCmu0PSls0CobBWPdztqpknW/181f2Krkz9eX7/7NmeXmOsXusiMjQkgeDvlJR6m+aY J+r3Axu28klbNrfr5dhj1GgikhcXJ/24ibs8xzzn1Z/aGkfu8VLZbyrn7av9+u8L/njs9z/YD3ub 2ejl7cPxhZzjuDjeFzlpadlpqW4zZvULmHL8u281OK5633cqqfzcUFkPW7t88+HbnwAAAAAAmhES UfrVKz95vicvLj4fFRkzawYR/bpkUUOuOkk7lZR58wYRmUgkTKTr0KFElHoq6e/TKURk5zaQiesb GhGRo7dPZxfXoqzMo2tWc5fXrmd5SqWa5cmmx+gxRJS8LbQ4N+dpfj7zkzjjxMYfSvLyHl+9QkSt u73OnQ+3uyf/ZL5Xt3N04s6/Xn9F7KooLb1+6Ld66wlKOKT4TxFkyt87eYLJp+vQYdz1t+3Vq6b8 iT+Vi9Wbv5p5stXP0NZFVerP8wd/nSEiq9e62Dg4EFG9p/8Q5zwhPuOlElv5ktzclLCtlq92sny1 0+kdYczP+xzlOeY5L5qNowZU9pvKeZt1767yxitisQbNcb8vlN6/jhpUXm/9bNg+N/jWwysfrfQn AAAAAAC3mktUJLa2BiYmj69dtXFwqKqs/PfG9YZUWlleXitiKpES0ZQ9cTV/WlkxG8e+Xev6wfRO zi6dnF0qy8tPbgq5dfQIR3ntaniebFq1bk1EissKFNo5OvWXTbHo0F7fyJiIDE1MuPPhJi8qYjaM zc2586/X04J85T/51sOUV+RjIqm9QFOrfmMzc+Xy6rerZp5s9WuX+vPn8f/+Jy8ulr72Witr6+Kc nMw79Vz/xT1PSEvjpbL8vRMnBgTNFAgEymsKbOXZ5jlfTTaOKvtN9bxV3MKjupqINDsViPt98ez9 a2auQeX11s+G7XODbz388tFGfwIAAAAAcBOR0hUcHqtqTkyYGrf/4ML56VevaKuZ4pwcMxubHb4+ 8uJi5Xj6lctxH39oZG7++jsj+k2WOU/9gFk4YCvPofzpU31jY5GBQYVc3mR5snmSkSHu2LFV69b5 j557lMPgufNMJJID8z/LvncvMG4fCQQap0pEBqamzMbTwgLu/Ov3/B0ZOepRee4DU16RT3FONnf9 pYWFr1haGpiaCp7vgfrzVy9PtvobG1s+VRUVjy5eaNPdwcjM7Mbvh6i++1/WP0/UHi9eeRJRb18/ PQMDgUDg5OunuM6FrTzbPGcIBAKBnl5D8tH+OKrqN6552zDc9T97/xYUNEb9bNg+NxreD43dnwAA AAAA3IREFOoxIic19U7i8e3jxlZVVJzcvDHUY4QWVzeI6Naxo0TU29df39hY3LHj4E8+ZeLvLf/S qktXeXHxP5cvElH501Lu8hyyU+8Rka37wIasGvDNk821g78QkcvUaa9YWhqZm7tOD2LiQj0hEclL Srr8/10AGsLOzd3OzZ2I/rl0iTt/vvjWc/v4MeV87vz3GHf59CuXa8q7P3cxBd922cqz1c+odX1N vZ7m5xGRuU3bekty5H//7JlXxGKhnh5zFQY3vvNEW/1m3rZdzzFj/7l0MePmjZ6jx5i3bcddnm2e F+fkEJF1t9dtXQfUbb1uf2o2jg3Hd95yq3tc3PUrvX8vNkb9bOp+bnDXwzb/tZUP3/cjAAAAAAAb ERGZSq0ktrYX9kR16NNXKBLdP3Na681ciosR/B979x8cf10fePyzye53vyVIVLpnmWmZgwqm7ZdE wMBFPRuI06lGtyhjFIM/zkvgOqfx52g7c+eP1pn2KFszV3NYlFWU0sDKalu+dTPipdEYK2TFMVE5 FkuBu7bfwyqNpCzfb2Dvj935+j3gC7vMl3x4yeMxzLzf+STf/bwCO8zs87t5J5Ocfv7L9726eN// +d+3XrfYvr5541+e+9a3Pe9XfqX10EMHvv+9v/30VY//9Y/j65+44mVvn3vZf37Hee9+b/JEp/0f qzmP5ntf+uuHd3b2/dYFF32y/MB9933rus7Jf1/7Hwsvnr2k+N/+qJszRJ9Q4bTTTnnxSw/c9v2b P/uZx5+/V70+zq3XX7fnuIGzL3pjkiTf+eIXbq1c//hf/83PfPpZv/AL57zlPzzit2P0et+jff3R Hj9Jkr5sNkmSQw888PiPfKSbP3v1i6bf9PorP5XJZJ7c8ydJkrtvuaXVah3613/tJh32+jw5Vv/e XnzJpX3Z7O1fuSnT33/eu9/74ksubR9uerSvP9rz/BufuvLFs5e+8sO/d9fN33z03R/97/NJ/Hc8 Jnp93j6+R39fj//4P//Lzz/1pf/+H7+7efPVn3kqHv9oHv3/jcd/nKM9/4/VPAAAcKxk9u3bl/YM sHtOO+/889793trvffju9Vt2874nnHTSRVde1Vj5m/95+WW7eV+ehrr/RcUAAECSJNdf3/nLs69/ 4zHekPGSsX/X3jjpjWeWfa8urn3yT3e5bmT6+s583euTTOaOlb/ZzfsCAAA8c2TTHgB21Rfe867d v+klf7n/4Z2d731p/9233Lz7dwcAAHgmEDjgKeeHETiS5wMAADwV/IgKAAAAEJ7AAQAAAIQncAAA AADhCRwAAABAeAIHAAAAEJ7AAQAAAITX+TWxIxPTw+NT/bl8Y31pc6XS3N4anZxdrZTSHQ4AAACg G53AMTBYqJZmklZraKxYnFtIMn0by4vpTgYAAADQpU7gWKvOtzf1WrleK6c3DwAAAEDPnMEBAAAA hCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdw AAAAAOEJHAAAAEB4AgcAAAAQXra9jExMD49P9efyjfWlzZVKc3trdHJ2tVJKdzgAAACAbnQCx8Bg oVqaSVqtobFicW4hyfRtLC+mOxkAAABAlzqBY606397Ua+V6rZzePAAAAAA9cwYHAAAAEJ7AAQAA AIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQn cAAAAADhCRwAAABAeNn2MjIxPTw+1Z/LN9aXNlcqze2t0cnZ1Uop3eEAAAAAutEJHAODhWppJmm1 hsaKxbmFJNO3sbyY7mQAAAAAXeoEjrXqfHtTr5XrtXJ68wAAAAD0zBkcAAAAQHgCBwAAABCewAEA AACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACE J3AAAAAA4WXby8jE9PD4VH8u31hf2lypNLe3RidnVyuldIcDAAAA6EYncAwMFqqlmaTVGhorFucW kkzfxvJiupMBAAAAdKkTONaq8+1NvVau18rpzQMAAADQM2dwAAAAAOEJHAAAAEB4AgcAAAAQnsAB AAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAA hJdtLyMT08PjU/25fGN9aXOl0tzeGp2cXa2U0h0OAAAAoBudwDEwWKiWZpJWa2isWJxbSDJ9G8uL 6U4GAAAA0KVO4Firzrc39Vq5XiunNw8AAABAz5zBAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7A AQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEF62vYxM TA+PT/Xn8o31pc2VSnN7a3RydrVSSnc4AAAAgG50AsfAYKFamklaraGxYnFuIcn0bSwvpjsZAAAA QJc6gWOtOt/e1Gvleq2c3jwAAAAAPXMGBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCe wAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHjZ9jIyMT08PtWf yzfWlzZXKs3trdHJ2dVKKd3hAAAAALrRCRwDg4VqaSZptYbGisW5hSTTt7G8mO5kAAAAAF3qBI61 6nx7U6+V67VyevMAAAAA9MwZHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQ nsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOFl28vIxPTw+FR/Lt9YX9pc qTS3t0YnZ1crpXSHAwAAAOhGJ3AMDBaqpZmk1RoaKxbnFpJM38byYrqTAQAAAHSpEzjWqvPtTb1W rtfK6c0DAAAA0DNncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAA EJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAISXbS8jE9PD41P9uXxjfWlzpdLc3hqd nF2tlNIdDgAAAKAbncAxMFiolmaSVmtorFicW0gyfRvLi+lOBgAAANClTuBYq863N/VauV4rpzcP AAAAQM+cwQEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAA ABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABBetr2MTEwPj0/15/KN9aXNlUpze2t0cna1Ukp3 OAAAAIBudALHwGChWppJWq2hsWJxbiHJ9G0sL6Y7GQAAAECXOoFjrTrf3tRr5XqtnN48AAAAAD1z BgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcA AAAQnsABAAAAhCdwAAAAAOEJHAAAAEB42fYyMjE9PD7Vn8s31pc2VyrN7a3RydnVSind4QAAAAC6 0QkcA4OFamkmabWGxorFuYUk07exvJjuZAAAAABd6gSOtep8e1Ovleu1cnrzAAAAAPTMGRwAAABA eAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIH AAAAEJ7AAQAAAIQncAAAAADhZdvLyMT08PhUfy7fWF/aXKk0t7dGJ2dXK6V0hwMAAADoRidwDAwW qqWZpNUaGisW5xaSTN/G8mK6kwEAAAB0qRM41qrz7U29Vq7XyunNAwAAANAzZ3AAAAAA4QkcAAAA QHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgC BwAAABCewAEAAACEl20vIxPTw+NT/bl8Y31pc6XS3N4anZxdrZTSHQ4AAACgG53AMTBYqJZmklZr aKxYnFtIMn0by4vpTgYAAADQpU7gWKvOtzf1WrleK6c3DwAAAEDPnMEBAAAAhCdwAAAAAOEJHAAA AEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4 AgcAAAAQXra9jExMD49P9efyjfWlzZVKc3trdHJ2tVJKdzgAAACAbnQCx8BgoVqaSVqtobFicW4h yfRtLC+mOxkAAABAlzqBY606397Ua+V6rZzePAAAAAA9cwYHAAAAEJ7AAQAAAIQncAAAAADhCRwA AABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABA eNn2MjIxPTw+1Z/LN9aXNlcqze2t0cnZ1Uop3eEAAAAAutEJHAODhWppJmm1hsaKxbmFJNO3sbyY 7mQAAAAAXeoEjrXqfHtTr5XrtXJ68wAAAAD0zBkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4Qkc AAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4WXby8jE 9PD4VH8u31hf2lypNLe3RidnVyuldIcDAAAA6EYncAwMFqqlmaTVGhorFucWkkzfxvJiupMBAAAA dKkTONaq8+1NvVau18rpzQMAAADQM2dwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJ HAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhJdtLyMT08PjU/25 fGN9aXOl0tzeGp2cXa2U0h0OAAAAoBudwDEwWKiWZpJWa2isWJxbSDJ9G8uL6U4GAAAA0KVO4Fir zrc39Vq5XiunNw8AAABAz5zBAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADh CRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEF62vYxMTA+PT/Xn8o31pc2V SnN7a3RydrVSSnc4AAAAgG50AsfAYKFamklaraGxYnFuIcn0bSwvpjsZAAAAQJc6gWOtOt/e1Gvl eq2c3jwAAAAAPXMGBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA 4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHjZ9jIyMT08PtWfyzfWlzZXKs3trdHJ 2dVKKd3hAAAAALrRCRwDg4VqaSZptYbGisW5hSTTt7G8mO5kAAAAAF3qBI616nx7U6+V67VyevMA AAAA9MwZHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAA AOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOFl28vIxPTw+FR/Lt9YX9pcqTS3t0YnZ1crpXSH AwAAAOhGJ3AMDBaqpZmk1RoaKxbnFpJM38byYrqTAQAAAHSpEzjWqvPtTb1WrtfK6c0DAAAA0DNn cAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAA AADhCRwAAABAeAIHAAAAEJ7AAQAAAISXbS8jE9PD41P9uXxjfWlzpdLc3hqdnF2tlNIdDgAAAKAb ncAxMFiolmaSVmtorFicW0gyfRvLi+lOBgAAANClTuBYq863N/VauV4rpzcPAAAAQM+cwQEAAACE J3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AA AAAA4QkcAAAAQHgCBwAAABBetr2MTEwPj0/15/KN9aXNlUpze2t0cna1Ukp3OAAAAIBudALHwGCh WppJWq2hsWJxbiHJ9G0sL6Y7GQAAAECXOoFjrTrf3tRr5XqtnN48AAAAAD1zBgcAAAAQnsABAAAA hCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdw AAAAAOEJHAAAAEB42fYyMjE9PD7Vn8s31pc2VyrN7a3RydnVSind4QAAAAC60QkcA4OFamkmabWG xorFuYUk07exvJjuZAAAAABd6gSOtep8e1Ovleu1cnrzAAAAAPTMGRwAAABAeAIHAAAAEJ7AAQAA AIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQn cAAAAADhZdvLyMT08PhUfy7fWF/aXKk0t7dGJ2dXK6V0hwMAAADoRidwDAwWqqWZpNUaGisW5xaS TN/G8mK6kwEAAAB0qRM41qrz7U29Vq7XyunNAwAAANAzZ3AAAAAA4QkcAAAAQHgCBwAAABCewAEA AACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACE l20vIxPTw+NT/bl8Y31pc6XS3N4anZxdrZTSHQ4AAACgG53AMTBYqJZmklZraKxYnFtIMn0by4vp TgYAAADQpU7gWKvOtzf1WrleK6c3DwAAAEDPnMEBAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsAB AAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQXra9jExM D49P9efyjfWlzZVKc3trdHJ2tVJKdzgAAACAbnQCx8BgoVqaSVqtobFicW4hyfRtLC+mOxkAAABA lzqBY606397Ua+V6rZzePAAAAAA9cwYHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7A AQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeNn2MjIxPTw+1Z/L N9aXNlcqze2t0cnZ1Uop3eEAAAAAutEJHAODhWppJmm1hsaKxbmFJNO3sbyY7mQAAAAAXeoEjrXq fHtTr5XrtXJ68wAAAAD0zBkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCe wAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4WXby8jE9PD4VH8u31hf2lyp NLe3RidnVyuldIcDAAAA6EYncAwMFqqlmaTVGhorFucWkkzfxvJiupMBAAAAdKkTONaq8+1NvVau 18rpzQMAAADQM2dwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQ nsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhJdtLyMT08PjU/25fGN9aXOl0tzeGp2c Xa2U0h0OAAAAoBudwDEwWKiWZpJWa2isWJxbSDJ9G8uL6U4GAAAA0KVO4Firzrc39Vq5XiunNw8A AABAz5zBAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAA EJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEF62vYxMTA+PT/Xn8o31pc2VSnN7a3RydrVSSnc4 AAAAgG50AsfAYKFaQH1B+AAAIABJREFUmklaraGxYnFuIcn0bSwvpjsZAAAAQJc6gWOtOt/e1Gvl eq2c3jwAAAAAPXMGBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA 4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHjZ9jIyMT08PtWfyzfWlzZXKs3trdHJ 2dVKKd3hAAAAALrRCRwDg4VqaSZptYbGisW5hSTTt7G8mO5kAAAAAF3qBI616nx7U6+V67VyevMA AAAA9MwZHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAA AOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOFl28vIxPTw+FR/Lt9YX9pcqTS3t0YnZ1crpXSH AwAAAOhGJ3AMDBaqpZmk1RoaKxbnFpJM38byYrqTAQAAAHSpEzjWqvPtTb1WrtfK6c0DAAAA0DNn cAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAA AADhCRwAAABAeAIHAAAAEJ7AAQAAAISXbS8jE9PD41P9uXxjfWlzpdLc3hqdnF2tlNIdDgAAAKAb ncAxMFiolmaSVmtorFicW0gyfRvLi+lOBgAAANClTuBYq863N/VauV4rpzcPAAAAQM+cwQEAAACE J3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AA AAAA4QkcAAAAQHgCBwAAABBetr2MTEwPj0/15/KN9aXNlUpze2t0cna1Ukp3OAAAAIBudALHwGCh WppJWq2hsWJxbiHJ9G0sL6Y7GQAAAECXOoFjrTrf3tRr5XqtnN48AAAAAD1zBgcAAAAQnsABAAAA hCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdw AAAAAOEJHAAAAEB42fYyMjE9PD7Vn8s31pc2VyrN7a3RydnVSind4QAAAAC60QkcA4OFamkmabWG xorFuYUk07exvJjuZAAAAABd6gSOtep8e1Ovleu1cnrzAAAAAPTMGRwAAABAeAIHAAAAEJ7AAQAA AIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQn cAAAAADhZdvLyMT08PhUfy7fWF/aXKk0t7dGJ2dXK6V0hwMAAADoRidwDAwWqqWZpNUaGisW5xaS TN/G8mK6kwEAAAB0qRM41qrz7U29Vq7XyunNAwAAANAzZ3AAAAAA4QkcAAAAQHgCBwAAABCewAEA AACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACE l20vIxPTw+NT/bl8Y31pc6XS3N4anZxdrZTSHQ4AAACgG53AMTBYqJZmklZraKxYnFtIMn0by4vp TgYAAADQpU7gWKvOtzf1WrleK6c3DwAAAEDPnMEBAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsAB AAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQXra9jExM D49P9efyjfWlzZVKc3trdHJ2tVJKdzgAAACAbnQCx8BgoVqaSVqtobFicW4hyfRtLC+mOxkAAABA lzqBY606397Ua+V6rZzePAAAAAA9cwYHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7A AQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeNn2MjIxPTw+1Z/L N9aXNlcqze2t0cnZ1Uop3eEAAAAAutEJHAODhWppJmm1hsaKxbmFJNO3sbyY7mQAAAAAXeoEjrXq fHtTr5XrtXJ68wAAAAD0zBkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCe wAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4WXby8jE9PD4VH8u31hf2lyp NLe3RidnVyuldIcDAAAA6EYncAwMFqqlmaTVGhorFucWkkzfxvJiupMBAAAAdKkTONaq8+1NvVau 18rpzQMAAADQM2dwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQ nsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhJdtLyMT08PjU/25fGN9aXOl0tzeGp2c Xa2U0h0OAAAAoBudwDEwWKiWZpJWa2isWJxbSDJ9G8uL6U4GAAAA0KVO4Firzrc39Vq5XiunNw8A AABAz5zBAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAA EJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEF62vYxMTA+PT/Xn8o31pc2VSnN7a3RydrVSSnc4 AAAAgG50AsfAYKFamklaraGxYnFuIcn0bSwvpjsZAAAAQJc6gWOtOt/e1Gvleq2c3jwAAAAAPXMG BwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAAABCewAEAAACEJ3AAAAAA4QkcAAAAQHgCBwAA ABCewAEAAACEJ3AAAAAA4QkcAAAAQHjZ9jIyMT08PtWfyzfWlzZXKs3trdHJ2dVKKd3hAAAAALrR CRwDg4VqaSZptYbGisW5hSTTt7G8mO5kAAAAAF3qBI616nx7U6+V67VyevMAAAAA9MwZHAAAAEB4 AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcAAAAQnsABAAAAhCdwAAAAAOEJHAAAAEB4AgcA AAAQnsABAAAAhCdwAAAAAOFl28vIxPTw+FR/Lt9YX9pcqTS3t0YnZ1crpXSHAwAAAOhGJ3AMDBaq pZmk1RoaKxbnFpJM38byYrqTAQAAAHSpEzjWqvPtTb1WrtfK6c0DAAAA0DNncAAAAADhCRwAAABA eAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIHAAAAEJ7AAQAAAIQncAAAAADhCRwAAABAeAIH AAAAEJ7AAQAAAISXbS8jE9PD41P9uXxjfWlzpdLc3hqdnF2tlNIdDgAAAKAbncAxMFiolmaSVmto rFicW0gyfRvLi+lOBgAAANClTuBYq863N/VauV4rpzcPAAAAQM+cwQEAAACEJ3AAAAAA4QkcAAAA QHgCBwAAABBAJpN5nCsCBwAAABDAic997iOuPPc5zzm8FzgAAACAAE455d8+4sqpR1zJ7tocAAAA wDPEF7/4mfbmggve2s31buzJ5UbPPuuuu+/Z2tp69rOfffIv/WIulzv8WYEDAAAAOMba/eJwznjC 613as2fPac//5cf81DEOHI8/+o03fvlTn/qzwx9ecMFb9+7d+9rXvvIlLzmnUHjuwYOHbrutceON X/72t7/7mN/qBRe89fD1hx566Ec/um99/duf/WzlgQeaR7svAAAAPEJPbyI42uvNE0541sUXX3j2 2cMnnHDC1tZWvf6da665YWvrJ8d00jBe/vKXvf3tb/v4x8s33fTVtGY4xoHjyJzx6CfK+ee/9HOf qzz44MHDV9797kvOPfesj33sT7/+9Vv27s2fccavvOENr/n2t7975KM95l327t37ute9+sILJ/fs 2fMnf3LV498XAAAADuv1TQSP+TLzfe/77Xvu+YcPfOCj99239exnn/Ca17zyfe/77Q9+8LJjNmUo 5557Vr3+nXPOOTPFwLGrh4xms9lf//WxI6+ceeYZSZJsbv6vnZ2d++/f/sY31n/ndz7azUM1m80b brgxSZKzzx55KkYFAACAx3H66b/8Z392ww9/+KOdnZ0f/vBH115bPf30U9MeKh35/J5f+7UXXHnl 5/btG8rn96Q1xq4GjrW1W37zN88/8spdd92TJMnll39oaqr4vOcVnsRj7tmTe+IvAgAAgCfr05+e v+GGq6666mMf+tB7zznnzPbFv/3b+kUXvebEE5/b399/4onPfcMbLvjGN+rpzpmWF75w3x133Hng wL133PH3L3zhvrTG+OmPqBz55pwj335ztOtPwl//9Vcuu+y/vuAFzz985fLLr7jkkjedddYZb3zj ay+66DVra+uf+MTVP/nJ/U94671791544auSJFlbW39yw+zC9wsAAEB0h18YHn/8wOmnn/rmN0+d fPIvfv7zf3XllZ/7yEfef9VVv9H+bKNx54c+9Az9+ZRzzjnzm9/8VpIkN9/8rdHRzn737epvUbn9 9h/84Ad3veIVP30Tx4ED9/7+7/9xoXDiS196zitf+fKXvGT0uOP2fuQjpfZnj9YXDjeItbVbrrji M0/pzAAAAJAkyf33b3/rWxv/8A8H/uiPPvj5z//VO985e/vtP7jsso//+Mf/8pznDL72ta985ztn /+AP/nvaY+62TCbzoheNLC5+MUmSm2++9XWve3Umk2m1Wrs/yU8Dx+Oc6HkM7/elL9106aVvecTF e+/95y984Utf+9o3P/WpPz7y/R1Hc8EFbz3++IHf/d13jI296Iwzhg4fStqT3fl+AQAA+Fny0EMP ZTKZJEle+MJ9b3vbu7a3/zVJknvv/edrrrnhqqs+lvZ0KRgaev7g4Amf/GTpyCvf/36jvT948OCe PbmDBw894k8d7foTOnjo0J5c56iKQ4cO5XI/PbZiV8/gSJLkq1/95oMPPnj4w49+9HfGxl50wgnP yuWyw8O/miTJ5uZt3TzO/fdvX3115eGHH37HO2aOP37gqRoXAACAZ5IvfvEzj/jtKh/84HvPPPOM 4477uXx+z2mnnfqe91z65S9/NUmSO+74u4svvrBQOLG/v79QOPHiiy9sNP4unaFTdc45Z1133V9c cMFb2/9cd91fHD6mJEmSO++85/zzX9rX98j4cLTrT6jRuOPgoUNJkuzs7DTu+MGRnzrGP6Jy5PPg MX9p68GDB7/yla/91m/9ZvvDanX/q171G+94x3/MZrM//vF9+/ff9Od//oXHfLRHP9Ttt//g059e nJmZvvTSN5dKVxzLbwMAAICfXYdfbD7idWv7r8//6Z/+75FffNNNX33DGy445ZRf2tl56B//8cDS 0t98+csrSZJcfvkVb3rT6/7wD//L4OCz/uVffnLrrZvPzFem5557Zqn0icMf3nzzre95z3+6+urr 2x9+8pPXvOtds5de+uZMJnPki/qjXX9CzQebjcYdp556yp1///cPNB848lOZfftSO+AUAAAAnj4m J1/+lre8/gMf+P0777w77Vn4qeuvv/7w/rvf+37zwWb7mI98Pr/vV3/18Kd2+0dUAAAA4Onp5S9/ 2ZVXflbdeDo77bTn783vbbVae/bsOf35/98hnt7BAQAAADx9HfkOjsfhHRwAAABAeAIHAAAAEJ7A AQAAAISXOXDgQNozwDH2vOc9L+0RnnYWFxfPO++8tKcAAAB+RnT5sms3m0N2eXn5tttu27X7JUny 4Q9/+OKLL97NOx7pmmuuSZIkxQF23zPwWz5w4IDG8QjnnXfeFVc8E38pNwAA8FTo5mXXgQMHdvNl SHb3/1L34osvftWrXrXLN32E1AfYfc/Ab5lHGxoaSnsEAADgZ8rJJ5/89re//f3vf3/7w8suu+zj H//43Xf/9Fft7trLkOzxxx+/y43jxhtv3M3bAYf5KRUAAOAYOvnkk/fv33/w4MFrr732jW9847XX XvuCF7zgFa94xeTk5OHGsTsvQ5aXlwMcMvr617/+yX19r3/waTvA7nsGfssAAAD05KSTTtq/f//P f+dz+cvP3tnZueuuu3Z2dvKXn/3z3/nc/v37TzrppF2eJ/uIj++6664777zz4YcfPlY3ePjhh/P5 /NjYWDb7yHvB00er1UqSJJPJPOk/9eQeAQAAIKidnZ1Dhw5lsnuSJDnrS2/OHrz0rK/8aZIkmeye Q4cO7ezs9PqABw/u3HPPvQcO3Le93Wy1kuOO2zM4eNwpp/ybn/t/7d15UFRX2jDw07f3pheWtpF9 3xQEBETQoKi4Aa4zaiWapBw/J3GSWVKZLzXJzFdvZZLMZCaZmZQZ9XUyKX3zasosEo2giBEFlVUE cQEBZW2goaGht3u7+977/XHGW22ztWhckudXU9bt0+eee+4lTNV9eM5zpBI+nz/l6fcEHRoaGvh8 /oYNGwQCAX5buy8sy7IsyzAMy7Lcax6Px+vo6Dh69OimTZsmOVcoFMbFxQUGBspkMpqmBwYGWlpa HmW11Uc2gc2bN/f19Z0/f96l8ciRI9MYzc/PLyYmRq1W22y23t7ehoYGm83m5rlP7y3HxcX5+PhQ FNXf39/Q0ECSpJvnajSaf/zjH8uWLfP09BwdHe3o6EhJSZnGHO4X/m06e/bssmXLuN+shxsQ2bFj x+9+97vw8PCHOCYAAAAAAAAATGJgYCAvL+/EiRP+69DgN+8Mf/ffCCH1ut9rozbk5eUNDAzc12j1 9bebmrqCgnwDAzVqtYqm6dFRc2trT0NDe3Cwd2JimFzuMXmY454AR1dX1/bt2/Hx/b4jJSQkcMdl ZWVCoVAkEgkEAoIgIiIiIiMjJz89MzPTYrGUl5ebzWahUKjRaGbPnv0oAxyPcgI2my0qKqqlpeXB h4qOjm5ubr5w4YJAIIiPj09PTy8vL3fz3Kf0lmNjY2/dutXf38+ybExMzPz588+dO+fmufv27Vu/ fv3atWuLi4vj4+PfeuutB5+P+5YsWbJr165//vOfD33kn/70p//1X/+1aNGi1tbWhz44AAAAAAAA AExEq9V2dHSE+UVzLWK/6I6ODq1W6/4gFGUvKqqRy2Xbtq3w9FQ4hyOSkqJ7ewdKSmpPnbq8eHG8 t7enUCicaJx7AhwSiQQfnDlzpqWlJTgoyMvb251IB/5b9P9rzEQIvZ1w6YsvvpBIJAMDA6GhoWvX rhUKhWq1evIRZsyYcezYMbvdjhCiKKqrq6urq4v7NiIiIi4uTiKRGAyGmpqakZERhBCPx4uLiwsP DxcKhT09PXV1ddNIgHksE6itrc3Jyenv7x8dHXX5iiCIxMTE4OBghFBnZ2dDQ8Pky4W4tAiHw1Ff X7927dof/C2XlpZyx83NzXFxcW7fMVqyZAmeDEVRly9f3rBhg0uHF1988c033wwODr558+YvfvGL S5cuIYR4PN6OHTteffXV8PDw7u7u3bt379mzZxopTidPnnz//fdPnTrV1tbm8hVBELt27dq1a1dI SEhnZ+fevXs//vhjN1eKLV++fPfu3Tk5OWOHBQAAAAAAAIDv1eHDh41GY88XzyOEZDELLc0XevY+ b1z1P7jmqDsjUJT92LGKoCDfNWsW8ng8h8NBkqTNZmMYhsfjyWSygADf555bXlBwvrj4yrJlCTNm qCeKcYxfZPTLr76609fHisV1V658V1Jy9rvvysrKyidWVlbmfPqxY8dOnz595MiR999/32az4XUr k9+STqdLS0tTq9XjJpz4+fmVlpZ+8803vb29qampuDE6Olqj0ZSWlhYWFhIEER8fP/WTezImYLfb a2tr09PTCcL1+c+aNUulUpWUlJSUlHh6es6aNcv9W/D19R0aGnK//9N+ywKBICoq6r5SToaHhxFC V69ePXDgwM9+9rOxmzZnZ2fPmzdv+/btSUlJn3zyCW586aWX9u/fX19fHxAQ8OWXX3788cc7d+50 /6Kc7du3W63WAwcOjH0Ir7766u7du0+fPh0QEFBSUvLRRx+98sor7oyZmZn52WefrVu3rrGxcRpT AgAAAAAAAIBpS0hI2Lhx46KBowgh9brfh/zutHrd7xFCiwaObty40XmdxyQqK29KJKI1axYihIxG o8FgaG/XVlXdLC+/evt2d1dXl1arJQhi48ZshUJaWdlkNBppmh53qHtetLj3Lg+ZbMXKlatzcjbv 2LFw1SqVWm2cwGefffbZZ58dOnTIeZyurq6rV6+SJBkWFqbX6+12+5QBjoqKitHR0ZSUlPXr1+fm 5iYmJjqHZGpra81ms8PhaGpq8vLywo3h4eGXL182m802m62+vj4wMNCdZ/eETECn0+l0urEBgpCQ kLq6OovFYrFY6urqQkJC3BzQy8srOTm5trbW/Tk81be8efPmjRs3RkdHX7lyxf05PP/883V1dT4+ Pi+88MInn3zS0dHx3HPPOXd48803DQbDl19+iRCKiYnBja+++ipC6O233x4ZGfnwww8RQr/85S/d vyinr69v586dCxcufO2111y+eumllxBCH3zwgcFg+Otf/4oQevnll90Z8+jRo1u3bq2srJzGfAAA AAAAAADgQTQ2Nubl5c185UjALw5pozakzl+gjdoQ8ItDM185kpeX585fYQ0G0+XLt9avz0IIjY6O jowYP//87Oefn7l6tam19c7x4xUFBZUtLe23b9/m8/n5+Znd3Yaurl6SJMfNqb9niQoX4PDx8fn6 0KHr9fVxSUmp8+alpKVdLC8//vnnPB7PecWK88oUDvfx7YRLCKE7d+7QND1l5Uu73X7t2rVr164h hFQqVWxs7Pz587lyElwVSZqmuXQDDw+P1atXu0xm2h79BBobG5ctW6bVagcHB7lGqVRqNpvxsclk kkql7gyl0WjS09MvXrxoNBrdn8BTfctHjhwRCoUxMTHz5s07e/asmxMoLy9PSUkJDAzMy8t79913 vb29//znPzuH53p6ehBCeNkO9+uAK3c6FxCJiopy84ouCgoKPv300z/+8Y+FhYXO7Tisg7NR8L94 zc6UfH19T58+7dLoXOUXAAAAAAAAAL4/JSUleXl577zzzvq8PK1Wm5eXV1BQ8Pu8vJKSEndOr65u io8P8/HxNJvNFEX97/+W0DSZkKBWKuX43fDGDW1RUV1+/lyJRBIUFBQQ4H3tWufMmWqxWDx2q9Z7 PnMvRXa7vbuzc+8//3n4m2/sFKWUyUQSicFgcHlrmvL99s6dO/X19Q6HY6IEknGNjIzU1dWtWbNm 8m4Wi+X8+fPcu/FD9GgmwDBMZWXlggULnH/wVqvVw8MDF6qQy+VWq3XKcYKDg5OSksrLy/H6i+l5 um4Zs9vtzc3NXJ6F+7q7u/ft21daWtrU1CSXy6fsr9Vqw8LCAgMDcfjjAf3qV79avHjxwYMHXaYU FRXl6+vb3d2NF850dna6M9q4v5IQ3QAAAAAAAAA8MiUlJWVlZRRFIYS0Wm1WVhY+dkdPz0BOTjrL siaT6cqVluFhQ1pagFqtVqvVUqmUx+P5+vqeOlVbVdXC47FBQUFxcSElJdUmk0mpVI4NcNyzRIX7 Q/3o6Oim7dtpls1fu/Zmc/Mf//Sn3X/60/Dw8NAYCKG3Ey7h/+FznT9qtVqtVjsyMjJlKcolS5YE BQVJJBKCIDw8PBITE6fcUaa1tTUtLU2pVBIEoVKpMjIy3HyCT84ERkdH29ranHcq7ezsnDt3rkwm k8lkycnJzm+5mzdvHjtCTExMYmLiuXPnphHdeEpvOT09HU9AJpMlJCTodDr3r37+/PnNmzf7+vqK RCK8WGZs+sNYH330EULogw8+UKvVCoVi1apVxcXF7l/Uhclk2rp169y5c50bDxw4gBB6/fXXVSrV b3/7W4TQvn378Fd49+VpXw4AAAAAAAAAvg+lpaX9d3V2do577LxHxLhu39aGh/tbrVa73V5Xd2vm TA+VSqXRaHx8fBQKhVwu9/b2zsqac+eOjiTJ4eHh0NCZg4NGi8UybpBh/CUqAqFQq9V++vnn54qL m65ds1GUWCIRCoXsXbgby7ISicRisRiNRpVKxY1z584dHo9ntVq9vLx4PJ47r2fXr1+PjIxMTU3l 8/kkSWq12inLCrS0tLAsu2DBArlcbjQaH7DI4uOawK1btxYtWsR9vHHjRmJiYk5ODkKoq6vrxo0b k5+elJSEEFq1ahXX8vXXX7u5s8lTestarTYjI0OpVJIk2dvbW1VV5f6lR0ZG3nvvPY1GIxaL+/r6 9u7d685OsR999JFOp/vNb36Dtym5ePEirsQxbRUVFe+9994f/vAHruUvf/kLj8d74YUXdu7c2dnZ +dprr+3evftBLgEAAAAAAAAA36vs7Oy9e/dO2S02NnaSb202h1QqJknSbrfbbHa1WobjGlz6BUEQ /v4as5m02+2Dg4Pe3t42m8Nms4372sszm80mkwl/qKqqys/PRwi9/vrrH374IQ8hP39/hULB4/GE QiFBEHg/FJqmcdFQHOzo6+tTqVSenp7cNrFtbW12u93hcAQFBb3++uvR0dF8Pj8xMRFfZe/evZPf 4feqqakJTfWIf2B+hLecnZ1dWlq6ZcuWxz2RJ0h/f//evXvdrF0KAAAAAAAAAO6YMkcjOzt7km/f eOO/9+37vyRJDg0NHTx42t9fNmdOlL+/v0Qi4fo4HI633vr35s1pERER3t7er7++Z9Om1PDwcG43 DG4m49fgwFiEBgcHaZoWi8UyDw8cz8ABDoyiKKPRSJIkHpdbpUJRFI6AyOXy6Ohob29vi8XCDRsb G3vixInJH8H3Jy8vDyH0GCfw6P0IbxkhlJ2dfV87yP7gTfn/OwAAAAAAAABwvyaPX0zJbrfbbDac kWG323k8JBKJuPQNjM/n2+12lmVpmrbb7Xif1vvYRQUf4HEtFgtN0w6HQywWO0c3bDYbSZJ4exSH w9Hf349b8IXxODKZLCAggCAI5xIj2dnZD/gIHtxjn8Cj92O7ZXdypX48YmNjm5qaflRZPAAAAAAA AIAnn81mpyg9o4aOAAAVJ0lEQVSKoii73W63OxhmnB0heTyezWZHCDkcDpvNho/HdU+AgwuT4AOx WCwUCvHiFD6fT9M0j8cTiUT4ejgIgoMoNE3jA6FQyOPx8BoWmqYFAoFEIqFpmgudAPBovPzyy5Cz wMHRjR9bkAsAAAAAAADwhGNZlqIom82G8zIm6YbuBjgmqfI5/hIVoVDI5/NFIpFIJBIKhQKBQCAQ 8Pl84i7uGlyAQyQSicVinFWCk0xMJhMex82alwA8XPA+z4FHAQAAAAAAwI8N3iQBIRQREfF4ZzIJ hUK2f/8Jh8PBMExPz1B2doxEIhEKhc59WJYVi0UIIYlEIpfL8fG4xl+iIhQKccACBzhwjAMHOPh8 vnPGCMMwDMM4HA6Hw8Hn87kgCN5FRSAQ4FSOh/kAAAAAAAAAAAAAMLGOjj5//3CxWHjt2vXz58sX LXrm4Y7vcDiamppaWlom7xYVFRUbGysQCCbqsHXr0p4erdVKsiwbE6OWyWQu0Q007SUqXICDz+fj 6IZzEgf/rrEZHI677HY7Dn8wDCMSibgAx9hVNAAAAAAAAAAAAPg+EISjru5Kfv7yZcueqai4cvp0 yfLlOQ9x/KampqGhofDw8Mm7DQ0NNTU1xcfHT9QhPj4qPj5qystNZ4mKc5FR0b1ckjhwN1y5FAc4 bDaby+oVfAoOgkw53R8MXABWLpc/rAHxAh+XxBkAAAAAAAAAAMDZwMDA8PCwzYY0Gk+JROzlJf3m m5Kf/GRFRkbypUuXWltbVSrVNIadMWPG2MbW1taIiAgcbsDvqtyLP/eRx+N5eXm1traODXBUVF9s bmny1cz0m+k35QRIK7locdKAvn9A348QWrQ4dtCgu37yalBA8Px5mR4yD67n+DU4uKgEj8fj8Xhc 6Q0+ny8QCJyjGLgKCMMwfD6fYRjc33kQHAFhWXZoaMjb2xshdO3aNZzHkpSUFBYWZjKZSkpK8LWU SqXPXVKp1HlujY2Nra2tLvc5e/bs6Oho55abN282NTW5dAsODk5JSZnyqT04o9H46aef2u329evX P5RlTiMjI/v370cIbd68OTg4+MEHBAAAAAAAAADwwzMwMIAQGhkZEYlmnDlTlpOzyGy2hYcH0zRD EISXl3dnZ2dCQsL0Rh43xoHf94VCIcuyBEHg1Rs4KwIHB5y3WHVRV385c/6ClORUvDHrlFLHvNA3 Xr96qfJiTGTshAEOLnLh7e0dGRmpUqmcK3E4lxrlQjK4AAcuLIoPbDYbLoI6OjoaFBTEBThIkkQI dXV1FRcXMwwTGhoaGhqKEKIoamzkAiG0ePHitLQ07uPAwMDYbv7+/i4tQ0NDY7uJxeJJn9VDo9fr 8Y+np6fnSa7j8tZbbyGE3n333cc9kf94EubzJMwBAAAAAAAAAB6QSuWxenXeyZPfpaTMjY4OHR01 C4UinU4fEeHr0vPw4cPc8bPPPjtluzMcFsD+/e9/BwcHr1y5UiQSMQxz6tSpzs7OHTt2cAkTY0+3 Wq1ent56vX5692glLT3aHqvVajQandvvCXDgyh8Oh2Pbtm1btmxBTlkYY+H1KdwB9xGHM/ABQRBW q5XbJtZoNB4/fpxhGE9Pz/z8fJc1F6GhoSKRaGRkZHBwkKbpc+fOIYScYxwIIZFI5LzIx8fHx+U+ cWiGoqiuri6EkL+/v0wm8/V1/UF+T0JCQtLS0sxm86NJGPmewKs+PAEAAAAAAADA0yg0NLSqqik/ P2fDhlw+nzAYjCzLGo16mVIz0NXcLRMGht5T8GLXrl0IoT179hw+fBjHMnB0g2uf5Fpc/CIkJKSw sFAikaxZs+b48eNFRUW5ublcBGTcc61Wq8Vidlm34SaadrR3tJMUabVaXfZsvSfAYTAYEEIsy+Ji osxdeCNYHMXAH3H8ggttOPfk/uXyO6RS6ejoqEgkKigosFgsQqFw3bp1EonEZZapqalhYWEIoZGR keLi4o6OjnPnzvn5+QUGBnJ95HJ5fn7+JLcaFxcXFxen1WoPHTqEEMrMzMRjcnQ6XWdnp8FgUCqV fn5+QUFBuJ1l2evXryOEIiIirl27RpLkwoULOzo6TCaTSqXSaDRNTU16vV6tVkdGRspkMoqi2tra +vv7vb29IyIicNENmqbVarVarcYbx/T39w8MDAiFwqioqBs3bvT398vl8tmzZ7tU6Ojv729vbzeb zRqNJjY2tru7G1+Um9tD96S9uj8J83kS5gAAAAAAAAAAD0gicRQUlGRlpYtEfIZhKYocHKYyZnn6 DZ4mLSdq6/5Pwtz5Lqfs2rULxzi4j1NehUvfYFl21apVIpHo6NGjnZ2dtbW169evX7p0Kd5sZKIY h9VqoWwURVH3e3cMw3R1d1I2ymG3W60Wl2/vCXCYTKbGxka8LIdLxMABC4vFgsuHODdyxxjee8U5 swPnbggEgv3790dGRup0OoTQqlWrxl3Aw1GpVPn5+Z9++qnFYuns7HQOcKC7RTex+yq9yTBMWVlZ bW2t8yqgmJiY5cuXSyQSmqZPnjyJEAoODu7s7AwICODxeDU1Ne3t7RqNhqKokZERfEptbW1eXl5h YeHg4CBu8fDweO6551QqFUVReJB169Yplcqmpqbq6mqJRFJRUYEXRCGEqqqqtmzZotFo8MeysrLq 6mpuSlVVVTweT6/Xx8bGuh/gYFm2qqqqsrLSYDB4enqmp6fPnz/fYrG8//77Go3mlVdeQQiRJPne e+8hhN544w18gF/pcbbCWJNkMbAsW1tbW1FRMTw8rFQqMzIy0tPT8Q/CeTQ+n6/RaNasWYOrh9A0 ferUqStXrlitVq6P8xzGzsdlhEmu6+bM3ZkDNwHI4wAAAAAAAAA8dRIT46urL+/bt18qlVss1jnJ aakxMtnttz1NVyS+nha0v+EySkz5T4xjz549OJyBYxzIKbrhTvoGj8djGEYsFm/YsKG7u/v06dPL ly/fsGGD2WzGW6xOGOAgSbvdZre7VYCD46Adff19Nopy0LTdYbeSpEuHewIcixYtKi4uLioqwhvP 4jgFj8dzOBxRUVFhYWF2u915QYpzLIPH4zU3N+v1erFY7Fw91Wq11tbWyuVyHN2YN29eTEzMlPOW SqWRkZFXr17t7u52bh8aGvr73//OfczKykpPT3fzWdTU1NTU1PB4PFz+Q6fTtba2Njc3EwSRl5fH dcOVV5wnqdPppFJpYmKiTqfr7e3V6/UHDx4UiUSzZ8/W6XQDAwNms7m6ujonZ/xNd0iStNlsERER LMvevn2boqjy8vKNGzcihK5fv15VVYUQIggiPDx8aGhoaGjIzdtxVlFRUVhYmJmZuXTp0jNnzpw4 cQIhlJGRERMTc+PGjd7eXj8/v5s3b9I0PXv2bA8Pj7EjzJ07Nzc3F6fVTPliX11dffz48eTk5J07 d164cOHbb78lCGLevHlch+Tk5Ly8vObm5i+++OLo0aO//vWvEULl5eWXLl1KT0/Pyck5ffp0dXX1 JHc07ghTXndK7syBi3FAaAMAAAAAAADwNJo3LyUuLrq9vZ0giNvXL8iFF/yFN6ReMtZqi/fps/fs q69lk1Iznn322cOHDzvHOLgRcHRjogIcyGmLEj6fT9N0QUFBTU3N8uXLa2pqCgoKli5dyufzcXbC uAEOkrRSlM1mt7t/UyRp1Q/p764XYWiaJkmrSx+By+cVK1aYzWaz2cyyrEgkQghdvHgRV/6QyWQC gcDhcHBxDQ5BEDqdTqlUMgxjNpsXLFgwc+ZMi8WCEOrp6dHr9ThiMtG9jQtvuaLVarldZx6E1Wq9 dOkSQmjhwoXz5/8nWHXnzp2vvvrq5s2bKSkpXFJJdHT0ypUrnc8lCGLTpk0ajcZut3/yyScmkwkh tGbNGrz45V//+pfBYMCreyayZMmS5ORkhNCXX37Z3t7OZXNcvHgR3+mWLVtw3OH69etFRUX3e3f4 RX3hwoUSieSZZ56pqKioqqrKyMhISUm5ceNGXV1dbm4uXoAzUXEQnMbi5uUqKioQQtnZ2RKJZOHC haWlpRUVFc6BBjxafHz8F198weW51NXVIYSysrKkUmlWVtbkAY5xR5jyutgkgYn7mgMAAAAAAAAA PKUUCgVenKH0kPQ1n4yY64MQw3MgHsukxAzbru69UoOS01xjHNiU0Q2EEK6+wefzhUJhUVHRt99+ +5Of/GTt2rXHjh376quv7Hb76tWrcaxg3Nd5lmUZlqEo1xSMcbEsazKZSNLKsCxNOxiGRXcXnbj0 dA1wIIQ8PDzwyzZOTMjLy9NoNCaTqb29XalUyuVyLrMDIYS3jx0eHhaJRNnZ2XgnmJKSEovFMmfO HIQQSZI4uuHp6WkwGKqrq8PCwtxZfIGrobosQlEoFCtWrOA+4iCIOwYGBnD0qL6+vqGhgWvHG9j0 9fVxAY6xY/r4+OAVJUKhUK1Wm0wmsVjMlfbQaDQGg4FbwDKWQCBITEzkOre3t+OdVrhlL85ZFbNm zSovL3epBDslHF7BpT3wv7glOjpaoVA0NDQsWbKkpaVFoVBERUWNO4JCoZhkfOdlI+++++7w8DBC 6G9/+xvX6FL8VqlUIoT4fD5y2gwZ3yy+EO4wiXFHmPK6U7qvOQAAAAAAAADA0y4oNKJ+8BVL5d6c ZRSSCZDZjozWjDiDuWrP1SuiOckpLjEOd6IbHJZlHQ5He3t7fn7+0qVLLRbL0qVLKYpqb293OBwT 7RGL4c1YxwzIOH90OGiapikbxSVu3I1uOHDhSxfjBDjuDuS4cOHCtm3b8EcPD4/g4OChoSGGYRQK hUQiwTEOkiR1Op1er5dKpYODgzNmzBAKhatXrz537lxHR0dISAg34JIlS4qLi81mc1FR0Ysvvjjl 1q09PT0IIZdqHUKh0KVoqJtw2gW6Gzdxgd+cMU9PT5dvnd+EZTKZSwvuP+7DxcRiMbcvjnORWJzh ghDi6nEghHg8nkajud8Ah1Kp1Ov1uDQpvlM8K4IgkpOTy8rKjh075nA4kpOTx92h534pFIrh4eE3 3njjvmIEKpVKr9ebzWalUjk6OvrIrvtw5wAAAAAAAAAAT5ek1Pl11Wxh4Z7VmwgeaUIdQ8jhWBZn +/Dc4bDIaIVCwcU4cH93ohtcfQ2BQPDyyy/j1AGKogQCQW5uLq5igf+daEEGyzA4wEEQBEHwGIbl QhgMy7DMfw4QQjRN07QDIcQwLD7AWRdjx5wwwNHT0xMQEIAQIkkS3U3/UCgUZrO5v78fL1ThdlcR i8UCgYCmaYqiWJaVSCTR0dEnTpxwDnBIpdKVK1d+/fXXo6OjZ86cyc3NneRhNTY29vX1IYRcKoxO m1qtxgfPP//8uLvGcrVL8V65zrj1NejuEpuxfSaB0xAw5/iCSqXC/xHcvHmT2/uWJMmOjg73B8fm zp1bUlJy4cKFpUuXlpeXI4S4hRspKSllZWWNjY1o4vUpLmQymcViGRoa4pJZXBZ9ZGZmFhYWnjx5 Mj8/n8/nd3R0XLp06cUXX3RzkkuWLCkrK7vPW7yP605SQcPNOYx9AgAAAAAAAADw9Jo7L+Myiwo+ +3h9KslTipHegawWAanr6uqaNWsWcjtlg4OXqBAE4ZKF4bwrCO4wUYADFwqVSiQIIRzdoGn6PxEN B40QYlhmbOIGQoimaVwTdOyYE76o+/v7HzlyJDIyEu8hwjAMvgeZTCaVSvFlcAv/LoSQ1WoVCoUW i+Xo0aPOiQlYeHh4UlJSfX39jRs3wsPD4+LinL/t6uqyWCwGg0Gv19+6dQshpFKpXCos2Gy2mzdv ch81Go2Pj89Et+BMrVZ7eXkNDw+XlJQsX75co9Ho9fqGhgapVJqUlDS93XcfEEEQYWFhbW1tt27d 0mg0CQkJo6OjlZWVLhv5uiMrKwshVFdXV1NTo1KpVq9enZGRgb9Sq9V4X5iQkBAuyjO5ZcuWfffd dx9++CGaIEyQmZkpl8svXrz4wQcfIIRCQkIWLFgw5bDPPPOM2Wyuq6vDlUemYXrXncYcpnwCAAAA AAAAAPBEmTFjBlftcVwp6Rm1CB0p/cemeXpCJmppF18fmRk13h4UY0ce2xgWFjY6OqpSqSZZh8Lj 8UZGRiZahDEyYlD7qEmSHJuvwQU18K6tLMs6aBo3IIRwksfweHUwJwxwCIXC3NzcAwcOJCYmciEA vMktDm1wyQjOO8UyDNPc3FxYWIh38Rw77OLFizs7O4eGhs6cORMYGOhc+gHvJ8KRSqWrV6/GhU45 JpMJbxGCZWVluRngIAhixYoVR44c6e3tPXjwoIeHh9lsxl9RFLV48WJ3Bnnoli1b1t3dTVHUuXPn ysrKmPFCUO4gCGLx4sUT3cXPf/5zlxbnl/axL/Dp6elT7k0zZ84cXGNlkpFdPvL5/NzcXJy5Y7Va 33nnHe6nP8l8XD5OdN1JTnHm5hzceQIAAAAAAAAA8EQZNxLhbFXemlqN5i+Fn/Atve1MYMaKNbNn z57e3/sjIyNbW1vb2tom7xYaGhoZGTm2naGZc2Wld9rveHh40DTNld7AO5qgu8U4cOKGcwtCiGFZ o9E4MmIYW8JjsqUWXl5eL7zwQmlp6f79+729vUNDQz09PZVKpUwmEwqFOM/E4XBQFDU6Ojo0NKTV atvb2xFCCxcuTE1NHXcdB46bHDp0iCTJoqKizZs33zMbgUAmk8lkMj8/v8zMTFzw4mEJCgraunVr SUlJX18fjm4olcq5c+empaU9xKvcF6VSuW3btqKiIq1Wi5cnpaam9vX1dXV1Pa4pfa/wdkEikejs 2bMIofj4+B/nHAAAAAAAAADgsUidNz86dlZ7e/szcrmfn9+0VzPw+fyYmJiYmJjpnf6nP/616NS3 bXduW61ubaTiQiySJCYkJSXMVSjuqc/IM5vNXAHOiVit1ra2ttu3bw8MDFgsFm59CkKIZVk+n08Q hEqlmjlzZmRkZFBQkHPaBcuyuACnc7yD29AFN3K74zqXq3CB00NcGl32WHGGxxy3A0VRBoNBoVC4 BFDGnoIvihcOObc4T9WlxXmQsZ3x0xh7pxaLxWg0ent7C4VCl4tOciNPnbq6urNnzxqNRk9Pz8TE xKysrPuqZvKDmQMAAAAAAAAA/Jg5HA6LxTxqNJIkOb2lDARBSCQSpUKhVKpwS2lpqVsBDgAAAAAA AAAAAIAnVmlp6UPYNBQAAAAAAAAAAADg8SIQQlar9XFPAwAAAAAAAAAAAGA6cFhDQJJkZWXl454M AAAAAAAAAAAAwDTl5OT8fxBN1O0ZmCnCAAAAAElFTkSuQmCC --===============7285067779541833994==-- From mlipchuk at redhat.com Tue Mar 11 16:59:19 2014 Content-Type: multipart/mixed; boundary="===============4527087808005023123==" MIME-Version: 1.0 From: Maor Lipchuk To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 22:08:09 +0200 Message-ID: <531F6D29.1090502@redhat.com> In-Reply-To: 531F29BD.20206@redhat.com --===============4527087808005023123== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/11/2014 05:20 PM, Itamar Heim wrote: > On 03/11/2014 05:14 PM, Eyal Edri wrote: >> >> >> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" >>> , users(a)ovirt.org, "infra" >>> Sent: Tuesday, March 11, 2014 5:10:54 PM >>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions >>> >>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: >>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: >>>>>> Tomasz Ko=C5=82ek wrote: >>>>>> >>>>>> I've got a few questions about project description. >>>>>> Please tell me if my problem's understanding is good or not. >>>>>> We need to add a few flags/methods to git review module. This flags >>>>>> should >>>>>> allow to add potential reviewers in gerrit. >>>>>> So: >>>>>> Let's assume that we've got special flags for this operations. What's >>>>>> next? >>>>>> 1. In gerrit system we need to add special place for potential >>>>>> reviewers? >>>>>> 2. Potential reviewers should agree that they want to review? >>>>>> 3. We can have more than one accepted reviewer? >>>>> >>>>> I'm not sure i understood exactly what you mean by 'potential >>>>> reviewers'. do want gerrit (hook?) to automatically add reviewers to >>>>> a patch according to the code sent? so in fact you'll have a place >>>>> somewhere for mapping code & specific developers? >>>> >>>> I really like this idea. Gerrit currently requires new users to know >>>> who >>>> to add as reviewers, IMHO impeding new contributors. >>>> >>>> One relative simple solution would be to look at who recently touched >>>> the files that are being modified and add them as reviewers. This >>>> can be >>>> done by looking at the git log for a file. Some pseudo python code >>>> solution: >>>> >>>> reviewers =3D set() >>>> >>>> for modified_file in commit.files: >>>> reviewers +=3D set(commit.author for commit in >>>> git.log(modified_file)) >>>> >>>> return reviewers >>>> >>>> This gives a system that those who touche a file, become the maintainer >>>> for that file. A more complex solution could improve on that and limit >>>> the reviewers added per patch. One can think of limiting to only >>>> contributions in the last X months, weigh contributions so common >>>> committers are prefered. It could also combine several methods. >>>> >>>> For example to limit to the 5 authors who touched the most files: >>>> >>>> reviewers =3D collections.Counter() # New in python 2.7 >>>> >>>> for modified_file in commit.files: >>>> reviewers +=3D collections.Counter(commit.author for commit in >>>> git.log(modified_file)) >>>> >>>> return [author for author, count in reviewers.most_common(5)] >>>> >>>> Since Counter also accepts a dictionary, one could also weigh the >>>> touched lines per file. Downside there is big whitespace/formatting >>>> patches can skew the line count. >>>> >>>> In short, I think an entire thesis could be written on the optimal way >>>> to determine reviewers but a simple algorithm could do to show the >>>> method works. >>>> >>>> Does this help? >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>> >>> I think if we do this, we want to make sure we cover per file who is >>> required to +2 it before we consider it acked. >>> >> >> won't it require maintaining static lists of people per >> file/path/project? >> > = > yes, but considering our project layout, i don't see an alternative. > (some of the layout could be improved to be path based, rather than file > based) I think it could be done automatically by analysing the file and see who mostly changed it recently, since the "owner" of the file might be dynamic, who ever changed most of it few days ago might be more familiar with it today IMO the algorithm of adding the reviewers should be flexible. For example, using a folder which will contain files, where each file implement an algorithm to add the reviewers. for instance we can have two files: 1. Add a reviewers by blame - the contributor which changed recently the code lines 2. Add a reviewers by file - the contributor who changed most of the file recently. Each file will implement the functional operation and will output the reviewers emails. The user can then add a new algorithm or change it to be more specific to its project. for example the user can add also the maintainers which acked the patch that was blamed. > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users --===============4527087808005023123==-- From tomasz-kolek at o2.pl Tue Mar 11 17:17:57 2014 Content-Type: multipart/mixed; boundary="===============6153648952679973659==" MIME-Version: 1.0 From: =?utf-8?q?Tomasz_Ko=C5=82ek_=3Ctomasz-kolek_at_o2=2Epl=3E?= To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Tue, 11 Mar 2014 22:17:50 +0100 Message-ID: <001f01cf3d6f$5ca47660$15ed6320$@o2.pl> In-Reply-To: 531F6678.5070104@redhat.com --===============6153648952679973659== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, Thank You for the answers, these give me basic look at the problem. Is not a problem (from my point of view) to implement a few flags for the c= ommand, like: add reviewers --auto --max=3D5 --using_blame etc, depends only on our req= uirements. I'm almost sure that good way is automatic way as Eyal mentioned, I know it= might make a little mess but will be easier for new contributor. Why almost? Because what with a situation where all of potential reviewers = are not interested to review patch? Maybe we should try to find "the most reviewing" people, maybe it will be g= ood way? BR, = Tomek -----Original Message----- From: Maor Lipchuk [mailto:mlipchuk(a)redhat.com] = Sent: Tuesday, March 11, 2014 8:40 PM To: Meital Bourvine; Eyal Edri Cc: Tomasz Ko=C5=82ek; users(a)ovirt.org; infra Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Hi Tomasz, I'm very please to hear that you are interested in the GSOC project, see my= answers inline. It's great to see that you know the material pretty well, I'm interested to= hear some more ideas and feedbacks. I will start a thread soon (Maybe also schedule a call) once getting more f= eedbacks from other contributors, so we can brain storm some more and get p= ractical with it. If you have any more questions, please don't hesitate to ask me. thanks, Maor On 03/11/2014 04:53 PM, Meital Bourvine wrote: > Eyal, > = > I think that he's asking about [1]. > = > As far as I understand, the idea is to automatically get the reviewers na= mes, with commands like `git blame`, or from gerrit - get previous reviewer= s to the same file/module... > = > Adding Maor, since he might have some additional info. > = > [1] = > http://www.ovirt.org/Summer_of_Code#Idea:_Gerrit_add_potential_reviewe > rs > = > ----- Original Message ----- >> From: "Eyal Edri" >> To: "Tomasz Ko=C5=82ek" >> Cc: users(a)ovirt.org, "infra" >> Sent: Tuesday, March 11, 2014 4:37:22 PM >> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - = >> questions >> >> >> >> ----- Original Message ----- >>> From: "Tomasz Ko=C5=82ek" >>> To: users(a)ovirt.org >>> Sent: Monday, March 10, 2014 9:56:28 PM >>> Subject: [Users] [GSOC][Gerrit] add potential reviewers - questions >>> >>> >>> >>> Hi >>> >>> I'd like to contribute (within GSOC) in idea: Gerrit add potential = >>> reviewers. >>> >>> Maybe at first I=E2=80=99ll introduce myself. >>> I'm Tomek, student from Poland. I study Computer Science at = >>> University of Wroclaw. The next year will be last year of my first degr= ee study, I hope. >>> As a python programmer I'm working since one year at Nokia Solutions = >>> and Networks (don't worry I intend to change my job to another or to = >>> participation at GSOC). Every day at work and school I'm using = >>> version control system (Git and SVN). At work we were using to = >>> Gerrit as a review system but currently we're using JIRA to report revi= ew statuses. >>> I love spend my free time in mountains (mainly polish - Tatras mountain= s). >>> That's all about me. >>> >>> I've got a few questions about project description. >>> Please tell me if my problem's understanding is good or not. >>> We need to add a few flags/methods to git review module. This flags = >>> should allow to add potential reviewers in gerrit. >>> So: >>> Let's assume that we've got special flags for this operations. What's n= ext? >>> 1. In gerrit system we need to add special place for potential reviewer= s? Adding a plugin to gerrit is an interesting idea although it will require t= he administrator to add it in the server, and I want that the operation wil= l be more available to any submitter in any project. I think that we can address it in a later phase though. >>> 2. Potential reviewers should agree that they want to review? no, since gerrit does not question the reviewer if he wants to be added or = not I think we should keep this behaviour as well. although as I see it, the operation of adding the reviewers, will not be co= mpletely automatic for the submitter, we should let the submitter of the pa= tch to choose which reviewers he wants to add, very similar to the screen b= eing used when doing a rebase in git. (see attached file add_reviewers.png) >>> 3. We can have more than one accepted reviewer? Yes, that is correct. >> >> Hi Tomasz, >> I'm not sure i understood exactly what you mean by 'potential reviewers'. >> do want gerrit (hook?) to automatically add reviewers to a patch = >> according to the code sent? >> so in fact you'll have a place somewhere for mapping code & specific = >> developers? >> >> cause if you mean by adding reviewers to a patch, that's easily done = >> by just clicking the '+' sign on each patch. >> those reviewers should have logged in at least once to = >> gerrit.ovirt.org in order to be in the list of potential viewers, and = >> they don't require any special permissions to review with +1/-1 any = >> patch sent. >> you can add as many reviewers as you want to a patch. >> >> does that answer your question? >> >> Eyal. >> >> >> >>> >>> I know above questions might seem chaotic but I think answers allow = >>> me to better understanding Yours needments >>> >>> Best regards >>> Tomasz Kolek >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> --===============6153648952679973659==-- From mlipchuk at redhat.com Tue Mar 11 23:17:45 2014 Content-Type: multipart/mixed; boundary="===============0686326213275028443==" MIME-Version: 1.0 From: Maor Lipchuk To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 05:17:08 +0200 Message-ID: <531FD1B4.3020804@redhat.com> In-Reply-To: 001f01cf3d6f$5ca47660$15ed6320$@o2.pl --===============0686326213275028443== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/11/2014 11:17 PM, Tomasz Ko=C5=82ek wrote: > Hi, > Thank You for the answers, these give me basic look at the problem. > = > Is not a problem (from my point of view) to implement a few flags for the= command, like: > add reviewers --auto --max=3D5 --using_blame etc, depends only on our r= equirements. > = > I'm almost sure that good way is automatic way as Eyal mentioned, I know = it might make a little mess but will be easier for new contributor. > Why almost? Because what with a situation where all of potential reviewer= s are not interested to review patch? > = > Maybe we should try to find "the most reviewing" people, maybe it will be= good way? That is another method of adding reviewers, see my suggestion in the thread which I addressed the way we should implement the algorithms for adding reviewers, so that it will be more generic. > = > = > BR, = > Tomek > = > -----Original Message----- > From: Maor Lipchuk [mailto:mlipchuk(a)redhat.com] = > Sent: Tuesday, March 11, 2014 8:40 PM > To: Meital Bourvine; Eyal Edri > Cc: Tomasz Ko=C5=82ek; users(a)ovirt.org; infra > Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > = > Hi Tomasz, > = > I'm very please to hear that you are interested in the GSOC project, see = my answers inline. > = > It's great to see that you know the material pretty well, I'm interested = to hear some more ideas and feedbacks. > I will start a thread soon (Maybe also schedule a call) once getting more= feedbacks from other contributors, so we can brain storm some more and get= practical with it. > If you have any more questions, please don't hesitate to ask me. > = > thanks, > Maor > = > On 03/11/2014 04:53 PM, Meital Bourvine wrote: >> Eyal, >> >> I think that he's asking about [1]. >> >> As far as I understand, the idea is to automatically get the reviewers n= ames, with commands like `git blame`, or from gerrit - get previous reviewe= rs to the same file/module... >> >> Adding Maor, since he might have some additional info. >> >> [1] = >> http://www.ovirt.org/Summer_of_Code#Idea:_Gerrit_add_potential_reviewe >> rs >> >> ----- Original Message ----- >>> From: "Eyal Edri" >>> To: "Tomasz Ko=C5=82ek" >>> Cc: users(a)ovirt.org, "infra" >>> Sent: Tuesday, March 11, 2014 4:37:22 PM >>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - = >>> questions >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Tomasz Ko=C5=82ek" >>>> To: users(a)ovirt.org >>>> Sent: Monday, March 10, 2014 9:56:28 PM >>>> Subject: [Users] [GSOC][Gerrit] add potential reviewers - questions >>>> >>>> >>>> >>>> Hi >>>> >>>> I'd like to contribute (within GSOC) in idea: Gerrit add potential = >>>> reviewers. >>>> >>>> Maybe at first I=E2=80=99ll introduce myself. >>>> I'm Tomek, student from Poland. I study Computer Science at = >>>> University of Wroclaw. The next year will be last year of my first deg= ree study, I hope. >>>> As a python programmer I'm working since one year at Nokia Solutions = >>>> and Networks (don't worry I intend to change my job to another or to = >>>> participation at GSOC). Every day at work and school I'm using = >>>> version control system (Git and SVN). At work we were using to = >>>> Gerrit as a review system but currently we're using JIRA to report rev= iew statuses. >>>> I love spend my free time in mountains (mainly polish - Tatras mountai= ns). >>>> That's all about me. >>>> >>>> I've got a few questions about project description. >>>> Please tell me if my problem's understanding is good or not. >>>> We need to add a few flags/methods to git review module. This flags = >>>> should allow to add potential reviewers in gerrit. >>>> So: >>>> Let's assume that we've got special flags for this operations. What's = next? >>>> 1. In gerrit system we need to add special place for potential reviewe= rs? > Adding a plugin to gerrit is an interesting idea although it will require= the administrator to add it in the server, and I want that the operation w= ill be more available to any submitter in any project. > I think that we can address it in a later phase though. >>>> 2. Potential reviewers should agree that they want to review? > no, since gerrit does not question the reviewer if he wants to be added o= r not I think we should keep this behaviour as well. > = > although as I see it, the operation of adding the reviewers, will not be = completely automatic for the submitter, we should let the submitter of the = patch to choose which reviewers he wants to add, very similar to the screen= being used when doing a rebase in git. (see attached file > add_reviewers.png) >>>> 3. We can have more than one accepted reviewer? > Yes, that is correct. >>> >>> Hi Tomasz, >>> I'm not sure i understood exactly what you mean by 'potential reviewers= '. >>> do want gerrit (hook?) to automatically add reviewers to a patch = >>> according to the code sent? >>> so in fact you'll have a place somewhere for mapping code & specific = >>> developers? >>> >>> cause if you mean by adding reviewers to a patch, that's easily done = >>> by just clicking the '+' sign on each patch. >>> those reviewers should have logged in at least once to = >>> gerrit.ovirt.org in order to be in the list of potential viewers, and = >>> they don't require any special permissions to review with +1/-1 any = >>> patch sent. >>> you can add as many reviewers as you want to a patch. >>> >>> does that answer your question? >>> >>> Eyal. >>> >>> >>> >>>> >>>> I know above questions might seem chaotic but I think answers allow = >>>> me to better understanding Yours needments >>>> >>>> Best regards >>>> Tomasz Kolek >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> > = > = --===============0686326213275028443==-- From iheim at redhat.com Wed Mar 12 03:16:35 2014 Content-Type: multipart/mixed; boundary="===============4668656177168010709==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 09:16:02 +0200 Message-ID: <532009B2.9070700@redhat.com> In-Reply-To: 531F6D29.1090502@redhat.com --===============4668656177168010709== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/11/2014 10:08 PM, Maor Lipchuk wrote: > On 03/11/2014 05:20 PM, Itamar Heim wrote: >> On 03/11/2014 05:14 PM, Eyal Edri wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" >>>> , users(a)ovirt.org, "infra" >>>> Sent: Tuesday, March 11, 2014 5:10:54 PM >>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions >>>> >>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: >>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: >>>>>>> Tomasz Ko=C5=82ek wrote: >>>>>>> >>>>>>> I've got a few questions about project description. >>>>>>> Please tell me if my problem's understanding is good or not. >>>>>>> We need to add a few flags/methods to git review module. This flags >>>>>>> should >>>>>>> allow to add potential reviewers in gerrit. >>>>>>> So: >>>>>>> Let's assume that we've got special flags for this operations. What= 's >>>>>>> next? >>>>>>> 1. In gerrit system we need to add special place for potential >>>>>>> reviewers? >>>>>>> 2. Potential reviewers should agree that they want to review? >>>>>>> 3. We can have more than one accepted reviewer? >>>>>> >>>>>> I'm not sure i understood exactly what you mean by 'potential >>>>>> reviewers'. do want gerrit (hook?) to automatically add reviewers to >>>>>> a patch according to the code sent? so in fact you'll have a place >>>>>> somewhere for mapping code & specific developers? >>>>> >>>>> I really like this idea. Gerrit currently requires new users to know >>>>> who >>>>> to add as reviewers, IMHO impeding new contributors. >>>>> >>>>> One relative simple solution would be to look at who recently touched >>>>> the files that are being modified and add them as reviewers. This >>>>> can be >>>>> done by looking at the git log for a file. Some pseudo python code >>>>> solution: >>>>> >>>>> reviewers =3D set() >>>>> >>>>> for modified_file in commit.files: >>>>> reviewers +=3D set(commit.author for commit in >>>>> git.log(modified_file)) >>>>> >>>>> return reviewers >>>>> >>>>> This gives a system that those who touche a file, become the maintain= er >>>>> for that file. A more complex solution could improve on that and limit >>>>> the reviewers added per patch. One can think of limiting to only >>>>> contributions in the last X months, weigh contributions so common >>>>> committers are prefered. It could also combine several methods. >>>>> >>>>> For example to limit to the 5 authors who touched the most files: >>>>> >>>>> reviewers =3D collections.Counter() # New in python 2.7 >>>>> >>>>> for modified_file in commit.files: >>>>> reviewers +=3D collections.Counter(commit.author for commit in >>>>> git.log(modified_file)) >>>>> >>>>> return [author for author, count in reviewers.most_common(5)] >>>>> >>>>> Since Counter also accepts a dictionary, one could also weigh the >>>>> touched lines per file. Downside there is big whitespace/formatting >>>>> patches can skew the line count. >>>>> >>>>> In short, I think an entire thesis could be written on the optimal way >>>>> to determine reviewers but a simple algorithm could do to show the >>>>> method works. >>>>> >>>>> Does this help? >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>> >>>> >>>> I think if we do this, we want to make sure we cover per file who is >>>> required to +2 it before we consider it acked. >>>> >>> >>> won't it require maintaining static lists of people per >>> file/path/project? >>> >> >> yes, but considering our project layout, i don't see an alternative. >> (some of the layout could be improved to be path based, rather than file >> based) > I think it could be done automatically by analysing the file and see who > mostly changed it recently, since the "owner" of the file might be > dynamic, who ever changed most of it few days ago might be more familiar > with it today > > IMO the algorithm of adding the reviewers should be flexible. > For example, using a folder which will contain files, where each file > implement an algorithm to add the reviewers. > > for instance we can have two files: > 1. Add a reviewers by blame - the contributor which changed recently the > code lines > 2. Add a reviewers by file - the contributor who changed most of the > file recently. > > Each file will implement the functional operation and will output the > reviewers emails. > > The user can then add a new algorithm or change it to be more specific > to its project. > for example the user can add also the maintainers which acked the patch > that was blamed. >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > this shouldn't be automatic. we need to clearly define ownership. we = can't do this per repo for the engine/vdsm. we can do this per repo for = the other repo's probably (though solving the folder/file approach would = cover the simpler repos as a private case). yes, it will require some work, maybe some moving around of files to = make this easier by folders (topics) which should be relevant anyway. --===============4668656177168010709==-- From dcaroest at redhat.com Wed Mar 12 05:40:08 2014 Content-Type: multipart/mixed; boundary="===============5427603172623664120==" MIME-Version: 1.0 From: David Caro To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 10:01:21 +0100 Message-ID: <53202261.301@redhat.com> In-Reply-To: 532009B2.9070700@redhat.com --===============5427603172623664120== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TrLXbbjhE3oQVQMOFxEnvJ7bNR05SlUqO Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: quoted-printable On Wed 12 Mar 2014 08:16:02 AM CET, Itamar Heim wrote: > On 03/11/2014 10:08 PM, Maor Lipchuk wrote: >> On 03/11/2014 05:20 PM, Itamar Heim wrote: >>> On 03/11/2014 05:14 PM, Eyal Edri wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Itamar Heim" >>>>> To: "Eyal Edri" , "Tomasz Ko=3DC5=3D82ek" >>>>> , users(a)ovirt.org, "infra" >>>>> Sent: Tuesday, March 11, 2014 5:10:54 PM >>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - quest= =3D ions >>>>> >>>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: >>>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: >>>>>>>> Tomasz Ko=3DC5=3D82ek wrote: >>>>>>>> >>>>>>>> I've got a few questions about project description. >>>>>>>> Please tell me if my problem's understanding is good or not. >>>>>>>> We need to add a few flags/methods to git review module. This fl= =3D ags >>>>>>>> should >>>>>>>> allow to add potential reviewers in gerrit. >>>>>>>> So: >>>>>>>> Let's assume that we've got special flags for this operations. W= =3D hat's >>>>>>>> next? >>>>>>>> 1. In gerrit system we need to add special place for potential >>>>>>>> reviewers? >>>>>>>> 2. Potential reviewers should agree that they want to review? >>>>>>>> 3. We can have more than one accepted reviewer? >>>>>>> >>>>>>> I'm not sure i understood exactly what you mean by 'potential >>>>>>> reviewers'. do want gerrit (hook?) to automatically add reviewer= =3D s to >>>>>>> a patch according to the code sent? so in fact you'll have a pla= =3D ce >>>>>>> somewhere for mapping code & specific developers? >>>>>> >>>>>> I really like this idea. Gerrit currently requires new users to kn= =3D ow >>>>>> who >>>>>> to add as reviewers, IMHO impeding new contributors. >>>>>> >>>>>> One relative simple solution would be to look at who recently touc= =3D hed >>>>>> the files that are being modified and add them as reviewers. This >>>>>> can be >>>>>> done by looking at the git log for a file. Some pseudo python code= =3D >>>>>> solution: >>>>>> >>>>>> reviewers =3D3D set() >>>>>> >>>>>> for modified_file in commit.files: >>>>>> reviewers +=3D3D set(commit.author for commit in >>>>>> git.log(modified_file)) >>>>>> >>>>>> return reviewers >>>>>> >>>>>> This gives a system that those who touche a file, become the maint= =3D ainer >>>>>> for that file. A more complex solution could improve on that and l= =3D imit >>>>>> the reviewers added per patch. One can think of limiting to only >>>>>> contributions in the last X months, weigh contributions so common >>>>>> committers are prefered. It could also combine several methods. >>>>>> >>>>>> For example to limit to the 5 authors who touched the most files: >>>>>> >>>>>> reviewers =3D3D collections.Counter() # New in python 2.7 >>>>>> >>>>>> for modified_file in commit.files: >>>>>> reviewers +=3D3D collections.Counter(commit.author for commit= =3D in >>>>>> git.log(modified_file)) >>>>>> >>>>>> return [author for author, count in reviewers.most_common(5)] >>>>>> >>>>>> Since Counter also accepts a dictionary, one could also weigh the >>>>>> touched lines per file. Downside there is big whitespace/formattin= =3D g >>>>>> patches can skew the line count. >>>>>> >>>>>> In short, I think an entire thesis could be written on the optimal= =3D way >>>>>> to determine reviewers but a simple algorithm could do to show the= =3D >>>>>> method works. >>>>>> >>>>>> Does this help? >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>> >>>>> >>>>> I think if we do this, we want to make sure we cover per file who i= =3D s >>>>> required to +2 it before we consider it acked. >>>>> >>>> >>>> won't it require maintaining static lists of people per >>>> file/path/project? >>>> >>> >>> yes, but considering our project layout, i don't see an alternative. >>> (some of the layout could be improved to be path based, rather than f= =3D ile >>> based) >> I think it could be done automatically by analysing the file and see w= =3D ho >> mostly changed it recently, since the "owner" of the file might be >> dynamic, who ever changed most of it few days ago might be more famili= =3D ar >> with it today >> >> IMO the algorithm of adding the reviewers should be flexible. >> For example, using a folder which will contain files, where each file >> implement an algorithm to add the reviewers. >> >> for instance we can have two files: >> 1. Add a reviewers by blame - the contributor which changed recently t= =3D he >> code lines >> 2. Add a reviewers by file - the contributor who changed most of the >> file recently. >> >> Each file will implement the functional operation and will output the >> reviewers emails. >> >> The user can then add a new algorithm or change it to be more specific= =3D >> to its project. >> for example the user can add also the maintainers which acked the patc= =3D h >> that was blamed. >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> > > this shouldn't be automatic. we need to clearly define ownership. we ca= =3D n't do > this per repo for the engine/vdsm. we can do this per repo for the othe= =3D r > repo's probably (though solving the folder/file approach would cover th= =3D e > simpler repos as a private case). > > yes, it will require some work, maybe some moving around of files to ma= =3D ke this > easier by folders (topics) which should be relevant anyway. I think it would easier to maintain if we just have one file at the=3D20 root, instead of having the ownership information distributed=3D20 throughout the files/directories. That way you'll know where to look at=3D20 to check/modify the ownership as opposed to having to walk all the=3D20 files and upper directories. Also, adding all that ownership logic to gerrit might not be easy, as=3D20 it's not meant to go checking the source of the repositories looking=3D20 for configuration. We might want to take a look (again) to zuul, the=3D20 tool that openstack uses as gateway to trigger jenkins jobs and merge=3D20 patches. > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --TrLXbbjhE3oQVQMOFxEnvJ7bNR05SlUqO Content-Type: application/pgp-signature; name=3D"signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=3D"signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTICJhAAoJEEBxx+HSYmnD5ccH+wbSsPmCAiK9sq8XPXvgaeMb 8x62a2DALqe5q8J4tGNQx/EtHw/GKFJT21jBiNHP5zZWbTSKzHcri2qlMPBvgsGY wN+A7QMOE9OhV1/FvkOoZjDRp2LFZ7GtAPkrJEljDVtCqOtyvkyekFeReMhraToW Gppx7/d3Z73tr4gh9r0J8+2r3/HHS4bZn71mWSGyogmMQpRUEPWfzZIuwKilmb3x b+RYxO72LB9JLQ3TKm1IZxHwyw93FRChWwkMGXYHrgNQ5yQKoltFuvz/Qa2yfVVh Qy32F1mxsAv9E0z0A0LuTHXJpvObf1PmMbvoICAc7ETxNOHtqGDLoTPNYPIyhl8=3D =3DqGqi -----END PGP SIGNATURE----- --TrLXbbjhE3oQVQMOFxEnvJ7bNR05SlUqO-- --===============5427603172623664120== Content-Type: multipart/signed MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhbiBPcGVuUEdQL01JTUUgc2lnbmVkIG1lc3NhZ2UgKFJGQyA0ODgwIGFuZCAzMTU2 KQotLVRyTFhiYmpoRTNvUVZRTU9GeEVudko3Yk5SMDVTbFVxTwpDb250ZW50LVR5cGU6IHRleHQv cGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXBy aW50YWJsZQoKT24gV2VkIDEyIE1hciAyMDE0IDA4OjE2OjAyIEFNIENFVCwgSXRhbWFyIEhlaW0g d3JvdGU6Cj4gT24gMDMvMTEvMjAxNCAxMDowOCBQTSwgTWFvciBMaXBjaHVrIHdyb3RlOgo+PiBP biAwMy8xMS8yMDE0IDA1OjIwIFBNLCBJdGFtYXIgSGVpbSB3cm90ZToKPj4+IE9uIDAzLzExLzIw MTQgMDU6MTQgUE0sIEV5YWwgRWRyaSB3cm90ZToKPj4+Pgo+Pj4+Cj4+Pj4gLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLQo+Pj4+PiBGcm9tOiAiSXRhbWFyIEhlaW0iIDxpaGVpbUByZWRoYXQu Y29tPgo+Pj4+PiBUbzogIkV5YWwgRWRyaSIgPGVlZHJpQHJlZGhhdC5jb20+LCAiVG9tYXN6IEtv PUM1PTgyZWsiCj4+Pj4+IDx0b21hc3ota29sZWtAbzIucGw+LCB1c2Vyc0BvdmlydC5vcmcsICJp bmZyYSIgPGluZnJhQG92aXJ0Lm9yZz4KPj4+Pj4gU2VudDogVHVlc2RheSwgTWFyY2ggMTEsIDIw MTQgNToxMDo1NCBQTQo+Pj4+PiBTdWJqZWN0OiBSZTogW1VzZXJzXSBbR1NPQ11bR2Vycml0XSBh ZGQgcG90ZW50aWFsIHJldmlld2VycyAtIHF1ZXN0PQppb25zCj4+Pj4+Cj4+Pj4+IE9uIDAzLzEx LzIwMTQgMDU6MDYgUE0sIEV3b3VkIEtvaGwgdmFuIFdpam5nYWFyZGVuIHdyb3RlOgo+Pj4+Pj4g T24gVHVlLCBNYXIgMTEsIDIwMTQgYXQgMTA6Mzc6MjJBTSAtMDQwMCwgRXlhbCBFZHJpIHdyb3Rl Ogo+Pj4+Pj4+PiBUb21hc3ogS289QzU9ODJlayB3cm90ZToKPj4+Pj4+Pj4KPj4+Pj4+Pj4gSSd2 ZSBnb3QgYSBmZXcgcXVlc3Rpb25zIGFib3V0IHByb2plY3QgZGVzY3JpcHRpb24uCj4+Pj4+Pj4+ IFBsZWFzZSB0ZWxsIG1lIGlmIG15IHByb2JsZW0ncyB1bmRlcnN0YW5kaW5nIGlzIGdvb2Qgb3Ig bm90Lgo+Pj4+Pj4+PiBXZSBuZWVkIHRvIGFkZCBhIGZldyBmbGFncy9tZXRob2RzIHRvIGdpdCBy ZXZpZXcgbW9kdWxlLiBUaGlzIGZsPQphZ3MKPj4+Pj4+Pj4gc2hvdWxkCj4+Pj4+Pj4+IGFsbG93 IHRvIGFkZCBwb3RlbnRpYWwgcmV2aWV3ZXJzIGluIGdlcnJpdC4KPj4+Pj4+Pj4gU286Cj4+Pj4+ Pj4+IExldCdzIGFzc3VtZSB0aGF0IHdlJ3ZlIGdvdCBzcGVjaWFsIGZsYWdzIGZvciB0aGlzIG9w ZXJhdGlvbnMuIFc9CmhhdCdzCj4+Pj4+Pj4+IG5leHQ/Cj4+Pj4+Pj4+IDEuIEluIGdlcnJpdCBz eXN0ZW0gd2UgbmVlZCB0byBhZGQgc3BlY2lhbCBwbGFjZSBmb3IgcG90ZW50aWFsCj4+Pj4+Pj4+ IHJldmlld2Vycz8KPj4+Pj4+Pj4gMi4gUG90ZW50aWFsIHJldmlld2VycyBzaG91bGQgYWdyZWUg dGhhdCB0aGV5IHdhbnQgdG8gcmV2aWV3Pwo+Pj4+Pj4+PiAzLiBXZSBjYW4gaGF2ZSBtb3JlIHRo YW4gb25lIGFjY2VwdGVkIHJldmlld2VyPwo+Pj4+Pj4+Cj4+Pj4+Pj4gSSdtIG5vdCBzdXJlIGkg dW5kZXJzdG9vZCBleGFjdGx5IHdoYXQgeW91IG1lYW4gYnkgJ3BvdGVudGlhbAo+Pj4+Pj4+IHJl dmlld2VycycuICBkbyB3YW50IGdlcnJpdCAoaG9vaz8pIHRvIGF1dG9tYXRpY2FsbHkgYWRkIHJl dmlld2VyPQpzIHRvCj4+Pj4+Pj4gYSBwYXRjaCBhY2NvcmRpbmcgdG8gdGhlIGNvZGUgc2VudD8g IHNvIGluIGZhY3QgeW91J2xsIGhhdmUgYSBwbGE9CmNlCj4+Pj4+Pj4gc29tZXdoZXJlIGZvciBt YXBwaW5nIGNvZGUgJiBzcGVjaWZpYyBkZXZlbG9wZXJzPwo+Pj4+Pj4KPj4+Pj4+IEkgcmVhbGx5 IGxpa2UgdGhpcyBpZGVhLiBHZXJyaXQgY3VycmVudGx5IHJlcXVpcmVzIG5ldyB1c2VycyB0byBr bj0Kb3cKPj4+Pj4+IHdobwo+Pj4+Pj4gdG8gYWRkIGFzIHJldmlld2VycywgSU1ITyBpbXBlZGlu ZyBuZXcgY29udHJpYnV0b3JzLgo+Pj4+Pj4KPj4+Pj4+IE9uZSByZWxhdGl2ZSBzaW1wbGUgc29s dXRpb24gd291bGQgYmUgdG8gbG9vayBhdCB3aG8gcmVjZW50bHkgdG91Yz0KaGVkCj4+Pj4+PiB0 aGUgZmlsZXMgdGhhdCBhcmUgYmVpbmcgbW9kaWZpZWQgYW5kIGFkZCB0aGVtIGFzIHJldmlld2Vy cy4gVGhpcwo+Pj4+Pj4gY2FuIGJlCj4+Pj4+PiBkb25lIGJ5IGxvb2tpbmcgYXQgdGhlIGdpdCBs b2cgZm9yIGEgZmlsZS4gU29tZSBwc2V1ZG8gcHl0aG9uIGNvZGU9Cgo+Pj4+Pj4gc29sdXRpb246 Cj4+Pj4+Pgo+Pj4+Pj4gcmV2aWV3ZXJzID0zRCBzZXQoKQo+Pj4+Pj4KPj4+Pj4+IGZvciBtb2Rp ZmllZF9maWxlIGluIGNvbW1pdC5maWxlczoKPj4+Pj4+ICAgICAgICByZXZpZXdlcnMgKz0zRCBz ZXQoY29tbWl0LmF1dGhvciBmb3IgY29tbWl0IGluCj4+Pj4+PiBnaXQubG9nKG1vZGlmaWVkX2Zp bGUpKQo+Pj4+Pj4KPj4+Pj4+IHJldHVybiByZXZpZXdlcnMKPj4+Pj4+Cj4+Pj4+PiBUaGlzIGdp dmVzIGEgc3lzdGVtIHRoYXQgdGhvc2Ugd2hvIHRvdWNoZSBhIGZpbGUsIGJlY29tZSB0aGUgbWFp bnQ9CmFpbmVyCj4+Pj4+PiBmb3IgdGhhdCBmaWxlLiBBIG1vcmUgY29tcGxleCBzb2x1dGlvbiBj b3VsZCBpbXByb3ZlIG9uIHRoYXQgYW5kIGw9CmltaXQKPj4+Pj4+IHRoZSByZXZpZXdlcnMgYWRk ZWQgcGVyIHBhdGNoLiBPbmUgY2FuIHRoaW5rIG9mIGxpbWl0aW5nIHRvIG9ubHkKPj4+Pj4+IGNv bnRyaWJ1dGlvbnMgaW4gdGhlIGxhc3QgWCBtb250aHMsIHdlaWdoIGNvbnRyaWJ1dGlvbnMgc28g Y29tbW9uCj4+Pj4+PiBjb21taXR0ZXJzIGFyZSBwcmVmZXJlZC4gSXQgY291bGQgYWxzbyBjb21i aW5lIHNldmVyYWwgbWV0aG9kcy4KPj4+Pj4+Cj4+Pj4+PiBGb3IgZXhhbXBsZSB0byBsaW1pdCB0 byB0aGUgNSBhdXRob3JzIHdobyB0b3VjaGVkIHRoZSBtb3N0IGZpbGVzOgo+Pj4+Pj4KPj4+Pj4+ IHJldmlld2VycyA9M0QgY29sbGVjdGlvbnMuQ291bnRlcigpICAjIE5ldyBpbiBweXRob24gMi43 Cj4+Pj4+Pgo+Pj4+Pj4gZm9yIG1vZGlmaWVkX2ZpbGUgaW4gY29tbWl0LmZpbGVzOgo+Pj4+Pj4g ICAgICAgIHJldmlld2VycyArPTNEIGNvbGxlY3Rpb25zLkNvdW50ZXIoY29tbWl0LmF1dGhvciBm b3IgY29tbWl0PQogaW4KPj4+Pj4+ICAgICAgICBnaXQubG9nKG1vZGlmaWVkX2ZpbGUpKQo+Pj4+ Pj4KPj4+Pj4+IHJldHVybiBbYXV0aG9yIGZvciBhdXRob3IsIGNvdW50IGluIHJldmlld2Vycy5t b3N0X2NvbW1vbig1KV0KPj4+Pj4+Cj4+Pj4+PiBTaW5jZSBDb3VudGVyIGFsc28gYWNjZXB0cyBh IGRpY3Rpb25hcnksIG9uZSBjb3VsZCBhbHNvIHdlaWdoIHRoZQo+Pj4+Pj4gdG91Y2hlZCBsaW5l cyBwZXIgZmlsZS4gRG93bnNpZGUgdGhlcmUgaXMgYmlnIHdoaXRlc3BhY2UvZm9ybWF0dGluPQpn Cj4+Pj4+PiBwYXRjaGVzIGNhbiBza2V3IHRoZSBsaW5lIGNvdW50Lgo+Pj4+Pj4KPj4+Pj4+IElu IHNob3J0LCBJIHRoaW5rIGFuIGVudGlyZSB0aGVzaXMgY291bGQgYmUgd3JpdHRlbiBvbiB0aGUg b3B0aW1hbD0KIHdheQo+Pj4+Pj4gdG8gZGV0ZXJtaW5lIHJldmlld2VycyBidXQgYSBzaW1wbGUg YWxnb3JpdGhtIGNvdWxkIGRvIHRvIHNob3cgdGhlPQoKPj4+Pj4+IG1ldGhvZCB3b3Jrcy4KPj4+ Pj4+Cj4+Pj4+PiBEb2VzIHRoaXMgaGVscD8KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4+PiBVc2VycyBtYWlsaW5nIGxpc3QKPj4+Pj4+ IFVzZXJzQG92aXJ0Lm9yZwo+Pj4+Pj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xp c3RpbmZvL3VzZXJzCj4+Pj4+Pgo+Pj4+Pgo+Pj4+PiBJIHRoaW5rIGlmIHdlIGRvIHRoaXMsIHdl IHdhbnQgdG8gbWFrZSBzdXJlIHdlIGNvdmVyIHBlciBmaWxlIHdobyBpPQpzCj4+Pj4+IHJlcXVp cmVkIHRvICsyIGl0IGJlZm9yZSB3ZSBjb25zaWRlciBpdCBhY2tlZC4KPj4+Pj4KPj4+Pgo+Pj4+ IHdvbid0IGl0IHJlcXVpcmUgbWFpbnRhaW5pbmcgc3RhdGljIGxpc3RzIG9mIHBlb3BsZSBwZXIK Pj4+PiBmaWxlL3BhdGgvcHJvamVjdD8KPj4+Pgo+Pj4KPj4+IHllcywgYnV0IGNvbnNpZGVyaW5n IG91ciBwcm9qZWN0IGxheW91dCwgaSBkb24ndCBzZWUgYW4gYWx0ZXJuYXRpdmUuCj4+PiAoc29t ZSBvZiB0aGUgbGF5b3V0IGNvdWxkIGJlIGltcHJvdmVkIHRvIGJlIHBhdGggYmFzZWQsIHJhdGhl ciB0aGFuIGY9CmlsZQo+Pj4gYmFzZWQpCj4+IEkgdGhpbmsgaXQgY291bGQgYmUgZG9uZSBhdXRv bWF0aWNhbGx5IGJ5IGFuYWx5c2luZyB0aGUgZmlsZSBhbmQgc2VlIHc9CmhvCj4+IG1vc3RseSBj aGFuZ2VkIGl0IHJlY2VudGx5LCBzaW5jZSB0aGUgIm93bmVyIiBvZiB0aGUgZmlsZSBtaWdodCBi ZQo+PiBkeW5hbWljLCB3aG8gZXZlciBjaGFuZ2VkIG1vc3Qgb2YgaXQgZmV3IGRheXMgYWdvIG1p Z2h0IGJlIG1vcmUgZmFtaWxpPQphcgo+PiB3aXRoIGl0IHRvZGF5Cj4+Cj4+IElNTyB0aGUgYWxn b3JpdGhtIG9mIGFkZGluZyB0aGUgcmV2aWV3ZXJzIHNob3VsZCBiZSBmbGV4aWJsZS4KPj4gRm9y IGV4YW1wbGUsIHVzaW5nIGEgZm9sZGVyIHdoaWNoIHdpbGwgY29udGFpbiBmaWxlcywgd2hlcmUg ZWFjaCBmaWxlCj4+IGltcGxlbWVudCBhbiBhbGdvcml0aG0gdG8gYWRkIHRoZSByZXZpZXdlcnMu Cj4+Cj4+IGZvciBpbnN0YW5jZSB3ZSBjYW4gaGF2ZSB0d28gZmlsZXM6Cj4+IDEuIEFkZCBhIHJl dmlld2VycyBieSBibGFtZSAtIHRoZSBjb250cmlidXRvciB3aGljaCBjaGFuZ2VkIHJlY2VudGx5 IHQ9CmhlCj4+IGNvZGUgbGluZXMKPj4gMi4gQWRkIGEgcmV2aWV3ZXJzIGJ5IGZpbGUgLSB0aGUg Y29udHJpYnV0b3Igd2hvIGNoYW5nZWQgbW9zdCBvZiB0aGUKPj4gZmlsZSByZWNlbnRseS4KPj4K Pj4gRWFjaCBmaWxlIHdpbGwgaW1wbGVtZW50IHRoZSBmdW5jdGlvbmFsIG9wZXJhdGlvbiBhbmQg d2lsbCBvdXRwdXQgdGhlCj4+IHJldmlld2VycyBlbWFpbHMuCj4+Cj4+IFRoZSB1c2VyIGNhbiB0 aGVuIGFkZCBhIG5ldyBhbGdvcml0aG0gb3IgY2hhbmdlIGl0IHRvIGJlIG1vcmUgc3BlY2lmaWM9 Cgo+PiB0byBpdHMgcHJvamVjdC4KPj4gZm9yIGV4YW1wbGUgdGhlIHVzZXIgY2FuIGFkZCBhbHNv IHRoZSBtYWludGFpbmVycyB3aGljaCBhY2tlZCB0aGUgcGF0Yz0KaAo+PiB0aGF0IHdhcyBibGFt ZWQuCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ Pj4gVXNlcnMgbWFpbGluZyBsaXN0Cj4+PiBVc2Vyc0BvdmlydC5vcmcKPj4+IGh0dHA6Ly9saXN0 cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vycwo+Pgo+Cj4gdGhpcyBzaG91bGRuJ3Qg YmUgYXV0b21hdGljLiB3ZSBuZWVkIHRvIGNsZWFybHkgZGVmaW5lIG93bmVyc2hpcC4gd2UgY2E9 Cm4ndCBkbwo+IHRoaXMgcGVyIHJlcG8gZm9yIHRoZSBlbmdpbmUvdmRzbS4gd2UgY2FuIGRvIHRo aXMgcGVyIHJlcG8gZm9yIHRoZSBvdGhlPQpyCj4gcmVwbydzIHByb2JhYmx5ICh0aG91Z2ggc29s dmluZyB0aGUgZm9sZGVyL2ZpbGUgYXBwcm9hY2ggd291bGQgY292ZXIgdGg9CmUKPiBzaW1wbGVy IHJlcG9zIGFzIGEgcHJpdmF0ZSBjYXNlKS4KPgo+IHllcywgaXQgd2lsbCByZXF1aXJlIHNvbWUg d29yaywgbWF5YmUgc29tZSBtb3ZpbmcgYXJvdW5kIG9mIGZpbGVzIHRvIG1hPQprZSB0aGlzCj4g ZWFzaWVyIGJ5IGZvbGRlcnMgKHRvcGljcykgd2hpY2ggc2hvdWxkIGJlIHJlbGV2YW50IGFueXdh eS4KCkkgdGhpbmsgaXQgd291bGQgZWFzaWVyIHRvIG1haW50YWluIGlmIHdlIGp1c3QgaGF2ZSBv bmUgZmlsZSBhdCB0aGU9MjAKcm9vdCwgaW5zdGVhZCBvZiBoYXZpbmcgdGhlIG93bmVyc2hpcCBp bmZvcm1hdGlvbiBkaXN0cmlidXRlZD0yMAp0aHJvdWdob3V0IHRoZSBmaWxlcy9kaXJlY3Rvcmll cy4gVGhhdCB3YXkgeW91J2xsIGtub3cgd2hlcmUgdG8gbG9vayBhdD0yMAp0byBjaGVjay9tb2Rp ZnkgdGhlIG93bmVyc2hpcCBhcyBvcHBvc2VkIHRvIGhhdmluZyB0byB3YWxrIGFsbCB0aGU9MjAK ZmlsZXMgYW5kIHVwcGVyIGRpcmVjdG9yaWVzLgoKQWxzbywgYWRkaW5nIGFsbCB0aGF0IG93bmVy c2hpcCBsb2dpYyB0byBnZXJyaXQgbWlnaHQgbm90IGJlIGVhc3ksIGFzPTIwCml0J3Mgbm90IG1l YW50IHRvIGdvIGNoZWNraW5nIHRoZSBzb3VyY2Ugb2YgdGhlIHJlcG9zaXRvcmllcyBsb29raW5n PTIwCmZvciBjb25maWd1cmF0aW9uLiBXZSBtaWdodCB3YW50IHRvIHRha2UgYSBsb29rIChhZ2Fp bikgdG8genV1bCwgdGhlPTIwCnRvb2wgdGhhdCBvcGVuc3RhY2sgdXNlcyBhcyBnYXRld2F5IHRv IHRyaWdnZXIgamVua2lucyBqb2JzIGFuZCBtZXJnZT0yMApwYXRjaGVzLgoKPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IEluZnJhIG1haWxpbmcgbGlz dAo+IEluZnJhQG92aXJ0Lm9yZwo+IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0 aW5mby9pbmZyYQoKCgotLQpEYXZpZCBDYXJvCgpSZWQgSGF0IFMuTC4KQ29udGludW91cyBJbnRl Z3JhdGlvbiBFbmdpbmVlciAtIEVNRUEgRU5HIFZpcnR1YWxpemF0aW9uIFImRAoKRW1haWw6IGRj YXJvQHJlZGhhdC5jb20KV2ViOiB3d3cucmVkaGF0LmNvbQpSSFQgR2xvYmFsICM6IDgyLTYyNjA1 CgoKLS1UckxYYmJqaEUzb1FWUU1PRnhFbnZKN2JOUjA1U2xVcU8KQ29udGVudC1UeXBlOiBhcHBs aWNhdGlvbi9wZ3Atc2lnbmF0dXJlOyBuYW1lPSJzaWduYXR1cmUuYXNjIgpDb250ZW50LURlc2Ny aXB0aW9uOiBPcGVuUEdQIGRpZ2l0YWwgc2lnbmF0dXJlCkNvbnRlbnQtRGlzcG9zaXRpb246IGF0 dGFjaG1lbnQ7IGZpbGVuYW1lPSJzaWduYXR1cmUuYXNjIgoKLS0tLS1CRUdJTiBQR1AgU0lHTkFU VVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlRRWNCQUVCQWdBR0JRSlRJQ0poQUFvSkVFQnh4 K0hTWW1uRDVjY0grd2JTc1BtQ0FpSzlzcThYUFh2Z2FlTWIKOHg2MmEyREFMcWU1cThKNHRHTlF4 L0V0SHcvR0tGSlQyMWpCaU5IUDV6WldiVFNLekhjcmkycWxNUEJ2Z3NHWQp3TitBN1FNT0U5T2hW MS9GdmtPb1pqRFJwMkxGWjdHdEFQa3JKRWxqRFZ0Q3FPdHl2a3lla0ZlUmVNaHJhVG9XCkdwcHg3 L2QzWjczdHI0Z2g5cjBKOCsycjMvSEhTNGJabjcxbVdTR3lvZ21NUXBSVUVQV2Z6Wkl1d0tpbG1i M3gKYitSWXhPNzJMQjlKTFEzVEttMUlaeEh3eXc5M0ZSQ2hXd2tNR1hZSHJnTlE1eVFLb2x0RnV2 ei9RYTJ5ZlZWaApReTMyRjFteHNBdjlFMHowQTBMdVRIWEpwdk9iZjFQbU1idm9JQ0FjN0VUeE5P SHRxR0RMb1RQTllQSXlobDg9Cj1xR3FpCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQoKLS1U ckxYYmJqaEUzb1FWUU1PRnhFbnZKN2JOUjA1U2xVcU8tLQo= --===============5427603172623664120==-- From emesika at redhat.com Wed Mar 12 10:58:26 2014 Content-Type: multipart/mixed; boundary="===============5464935612933496387==" MIME-Version: 1.0 From: Eli Mesika To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 10:57:56 -0400 Message-ID: <121209076.16869658.1394636276950.JavaMail.zimbra@redhat.com> In-Reply-To: 53202261.301@redhat.com --===============5464935612933496387== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "David Caro" > To: "Itamar Heim" > Cc: "Maor Lipchuk" , users(a)ovirt.org, "Tomasz Ko= =C5=82ek" , "infra" > > Sent: Wednesday, March 12, 2014 11:01:21 AM > Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > = > On Wed 12 Mar 2014 08:16:02 AM CET, Itamar Heim wrote: > > On 03/11/2014 10:08 PM, Maor Lipchuk wrote: > >> On 03/11/2014 05:20 PM, Itamar Heim wrote: > >>> On 03/11/2014 05:14 PM, Eyal Edri wrote: > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Itamar Heim" > >>>>> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" > >>>>> , users(a)ovirt.org, "infra" > >>>>> Sent: Tuesday, March 11, 2014 5:10:54 PM > >>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - quest= ions > >>>>> > >>>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: > >>>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: > >>>>>>>> Tomasz Ko=C5=82ek wrote: > >>>>>>>> > >>>>>>>> I've got a few questions about project description. > >>>>>>>> Please tell me if my problem's understanding is good or not. > >>>>>>>> We need to add a few flags/methods to git review module. This fl= ags > >>>>>>>> should > >>>>>>>> allow to add potential reviewers in gerrit. > >>>>>>>> So: > >>>>>>>> Let's assume that we've got special flags for this operations. > >>>>>>>> What's > >>>>>>>> next? > >>>>>>>> 1. In gerrit system we need to add special place for potential > >>>>>>>> reviewers? > >>>>>>>> 2. Potential reviewers should agree that they want to review? > >>>>>>>> 3. We can have more than one accepted reviewer? > >>>>>>> > >>>>>>> I'm not sure i understood exactly what you mean by 'potential > >>>>>>> reviewers'. do want gerrit (hook?) to automatically add reviewer= s to > >>>>>>> a patch according to the code sent? so in fact you'll have a pla= ce > >>>>>>> somewhere for mapping code & specific developers? > >>>>>> > >>>>>> I really like this idea. Gerrit currently requires new users to kn= ow > >>>>>> who > >>>>>> to add as reviewers, IMHO impeding new contributors. > >>>>>> > >>>>>> One relative simple solution would be to look at who recently touc= hed > >>>>>> the files that are being modified and add them as reviewers. This > >>>>>> can be > >>>>>> done by looking at the git log for a file. Some pseudo python code > >>>>>> solution: > >>>>>> > >>>>>> reviewers =3D set() > >>>>>> > >>>>>> for modified_file in commit.files: > >>>>>> reviewers +=3D set(commit.author for commit in > >>>>>> git.log(modified_file)) > >>>>>> > >>>>>> return reviewers > >>>>>> > >>>>>> This gives a system that those who touche a file, become the > >>>>>> maintainer > >>>>>> for that file. A more complex solution could improve on that and l= imit > >>>>>> the reviewers added per patch. One can think of limiting to only > >>>>>> contributions in the last X months, weigh contributions so common > >>>>>> committers are prefered. It could also combine several methods. > >>>>>> > >>>>>> For example to limit to the 5 authors who touched the most files: > >>>>>> > >>>>>> reviewers =3D collections.Counter() # New in python 2.7 > >>>>>> > >>>>>> for modified_file in commit.files: > >>>>>> reviewers +=3D collections.Counter(commit.author for commit= in > >>>>>> git.log(modified_file)) > >>>>>> > >>>>>> return [author for author, count in reviewers.most_common(5)] > >>>>>> > >>>>>> Since Counter also accepts a dictionary, one could also weigh the > >>>>>> touched lines per file. Downside there is big whitespace/formatting > >>>>>> patches can skew the line count. > >>>>>> > >>>>>> In short, I think an entire thesis could be written on the optimal= way > >>>>>> to determine reviewers but a simple algorithm could do to show the > >>>>>> method works. > >>>>>> > >>>>>> Does this help? Maybe it will be worth to use the information we have in Bugzilla here: We can browse the BZ that were closed/verified in the last XXX days Per BZ , we know which patches are involved, who reviewed the patches, whic= h files were changed, when files were changed and the rank of the change (n= umber of lines changed) I believe that from this information we can compose a simple ranking algori= thm that its output will be a list of N potential reviewers for the patch. Since we can aggregate the above information for all files related to the p= atch we want to add reviewers, we can have this set for the whole patch. This information should be processed and stored each N days and gerrit will= be able to use it. > >>>>>> _______________________________________________ > >>>>>> Users mailing list > >>>>>> Users(a)ovirt.org > >>>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>>> > >>>>> > >>>>> I think if we do this, we want to make sure we cover per file who is > >>>>> required to +2 it before we consider it acked. > >>>>> > >>>> > >>>> won't it require maintaining static lists of people per > >>>> file/path/project? > >>>> > >>> > >>> yes, but considering our project layout, i don't see an alternative. > >>> (some of the layout could be improved to be path based, rather than f= ile > >>> based) > >> I think it could be done automatically by analysing the file and see w= ho > >> mostly changed it recently, since the "owner" of the file might be > >> dynamic, who ever changed most of it few days ago might be more famili= ar > >> with it today > >> > >> IMO the algorithm of adding the reviewers should be flexible. > >> For example, using a folder which will contain files, where each file > >> implement an algorithm to add the reviewers. > >> > >> for instance we can have two files: > >> 1. Add a reviewers by blame - the contributor which changed recently t= he > >> code lines > >> 2. Add a reviewers by file - the contributor who changed most of the > >> file recently. > >> > >> Each file will implement the functional operation and will output the > >> reviewers emails. > >> > >> The user can then add a new algorithm or change it to be more specific > >> to its project. > >> for example the user can add also the maintainers which acked the patch > >> that was blamed. > >>> _______________________________________________ > >>> Users mailing list > >>> Users(a)ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/users > >> > > > > this shouldn't be automatic. we need to clearly define ownership. we ca= n't > > do > > this per repo for the engine/vdsm. we can do this per repo for the other > > repo's probably (though solving the folder/file approach would cover the > > simpler repos as a private case). > > > > yes, it will require some work, maybe some moving around of files to ma= ke > > this > > easier by folders (topics) which should be relevant anyway. > = > I think it would easier to maintain if we just have one file at the > root, instead of having the ownership information distributed > throughout the files/directories. That way you'll know where to look at > to check/modify the ownership as opposed to having to walk all the > files and upper directories. > = > Also, adding all that ownership logic to gerrit might not be easy, as > it's not meant to go checking the source of the repositories looking > for configuration. We might want to take a look (again) to zuul, the > tool that openstack uses as gateway to trigger jenkins jobs and merge > patches. > = > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > = > = > = > -- > David Caro > = > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > = > Email: dcaro(a)redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > = > = > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra >=20 --===============5464935612933496387==-- From iheim at redhat.com Wed Mar 12 11:53:01 2014 Content-Type: multipart/mixed; boundary="===============3684310797714043661==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 17:52:25 +0200 Message-ID: <532082B9.3050400@redhat.com> In-Reply-To: 121209076.16869658.1394636276950.JavaMail.zimbra@redhat.com --===============3684310797714043661== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/12/2014 04:57 PM, Eli Mesika wrote: > > > ----- Original Message ----- >> From: "David Caro" >> To: "Itamar Heim" >> Cc: "Maor Lipchuk" , users(a)ovirt.org, "Tomasz K= o=C5=82ek" , "infra" >> >> Sent: Wednesday, March 12, 2014 11:01:21 AM >> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions >> >> On Wed 12 Mar 2014 08:16:02 AM CET, Itamar Heim wrote: >>> On 03/11/2014 10:08 PM, Maor Lipchuk wrote: >>>> On 03/11/2014 05:20 PM, Itamar Heim wrote: >>>>> On 03/11/2014 05:14 PM, Eyal Edri wrote: >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Itamar Heim" >>>>>>> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" >>>>>>> , users(a)ovirt.org, "infra" >>>>>>> Sent: Tuesday, March 11, 2014 5:10:54 PM >>>>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - quest= ions >>>>>>> >>>>>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: >>>>>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: >>>>>>>>>> Tomasz Ko=C5=82ek wrote: >>>>>>>>>> >>>>>>>>>> I've got a few questions about project description. >>>>>>>>>> Please tell me if my problem's understanding is good or not. >>>>>>>>>> We need to add a few flags/methods to git review module. This fl= ags >>>>>>>>>> should >>>>>>>>>> allow to add potential reviewers in gerrit. >>>>>>>>>> So: >>>>>>>>>> Let's assume that we've got special flags for this operations. >>>>>>>>>> What's >>>>>>>>>> next? >>>>>>>>>> 1. In gerrit system we need to add special place for potential >>>>>>>>>> reviewers? >>>>>>>>>> 2. Potential reviewers should agree that they want to review? >>>>>>>>>> 3. We can have more than one accepted reviewer? >>>>>>>>> >>>>>>>>> I'm not sure i understood exactly what you mean by 'potential >>>>>>>>> reviewers'. do want gerrit (hook?) to automatically add reviewer= s to >>>>>>>>> a patch according to the code sent? so in fact you'll have a pla= ce >>>>>>>>> somewhere for mapping code & specific developers? >>>>>>>> >>>>>>>> I really like this idea. Gerrit currently requires new users to kn= ow >>>>>>>> who >>>>>>>> to add as reviewers, IMHO impeding new contributors. >>>>>>>> >>>>>>>> One relative simple solution would be to look at who recently touc= hed >>>>>>>> the files that are being modified and add them as reviewers. This >>>>>>>> can be >>>>>>>> done by looking at the git log for a file. Some pseudo python code >>>>>>>> solution: >>>>>>>> >>>>>>>> reviewers =3D set() >>>>>>>> >>>>>>>> for modified_file in commit.files: >>>>>>>> reviewers +=3D set(commit.author for commit in >>>>>>>> git.log(modified_file)) >>>>>>>> >>>>>>>> return reviewers >>>>>>>> >>>>>>>> This gives a system that those who touche a file, become the >>>>>>>> maintainer >>>>>>>> for that file. A more complex solution could improve on that and l= imit >>>>>>>> the reviewers added per patch. One can think of limiting to only >>>>>>>> contributions in the last X months, weigh contributions so common >>>>>>>> committers are prefered. It could also combine several methods. >>>>>>>> >>>>>>>> For example to limit to the 5 authors who touched the most files: >>>>>>>> >>>>>>>> reviewers =3D collections.Counter() # New in python 2.7 >>>>>>>> >>>>>>>> for modified_file in commit.files: >>>>>>>> reviewers +=3D collections.Counter(commit.author for commi= t in >>>>>>>> git.log(modified_file)) >>>>>>>> >>>>>>>> return [author for author, count in reviewers.most_common(5)] >>>>>>>> >>>>>>>> Since Counter also accepts a dictionary, one could also weigh the >>>>>>>> touched lines per file. Downside there is big whitespace/formatting >>>>>>>> patches can skew the line count. >>>>>>>> >>>>>>>> In short, I think an entire thesis could be written on the optimal= way >>>>>>>> to determine reviewers but a simple algorithm could do to show the >>>>>>>> method works. >>>>>>>> >>>>>>>> Does this help? > > Maybe it will be worth to use the information we have in Bugzilla here: > > We can browse the BZ that were closed/verified in the last XXX days > Per BZ , we know which patches are involved, who reviewed the patches, wh= ich files were changed, when files were changed and the rank of the change = (number of lines changed) > I believe that from this information we can compose a simple ranking algo= rithm that its output will be a list of N potential reviewers for the patch. > Since we can aggregate the above information for all files related to the= patch we want to add reviewers, we can have this set for the whole patch. > This information should be processed and stored each N days and gerrit wi= ll be able to use it. why are we trying to invent hueristics, instead of declaring clear = ownership? > > >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users(a)ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>>>> >>>>>>> >>>>>>> I think if we do this, we want to make sure we cover per file who is >>>>>>> required to +2 it before we consider it acked. >>>>>>> >>>>>> >>>>>> won't it require maintaining static lists of people per >>>>>> file/path/project? >>>>>> >>>>> >>>>> yes, but considering our project layout, i don't see an alternative. >>>>> (some of the layout could be improved to be path based, rather than f= ile >>>>> based) >>>> I think it could be done automatically by analysing the file and see w= ho >>>> mostly changed it recently, since the "owner" of the file might be >>>> dynamic, who ever changed most of it few days ago might be more famili= ar >>>> with it today >>>> >>>> IMO the algorithm of adding the reviewers should be flexible. >>>> For example, using a folder which will contain files, where each file >>>> implement an algorithm to add the reviewers. >>>> >>>> for instance we can have two files: >>>> 1. Add a reviewers by blame - the contributor which changed recently t= he >>>> code lines >>>> 2. Add a reviewers by file - the contributor who changed most of the >>>> file recently. >>>> >>>> Each file will implement the functional operation and will output the >>>> reviewers emails. >>>> >>>> The user can then add a new algorithm or change it to be more specific >>>> to its project. >>>> for example the user can add also the maintainers which acked the patch >>>> that was blamed. >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>> >>> this shouldn't be automatic. we need to clearly define ownership. we ca= n't >>> do >>> this per repo for the engine/vdsm. we can do this per repo for the other >>> repo's probably (though solving the folder/file approach would cover the >>> simpler repos as a private case). >>> >>> yes, it will require some work, maybe some moving around of files to ma= ke >>> this >>> easier by folders (topics) which should be relevant anyway. >> >> I think it would easier to maintain if we just have one file at the >> root, instead of having the ownership information distributed >> throughout the files/directories. That way you'll know where to look at >> to check/modify the ownership as opposed to having to walk all the >> files and upper directories. >> >> Also, adding all that ownership logic to gerrit might not be easy, as >> it's not meant to go checking the source of the repositories looking >> for configuration. We might want to take a look (again) to zuul, the >> tool that openstack uses as gateway to trigger jenkins jobs and merge >> patches. >> >>> _______________________________________________ >>> Infra mailing list >>> Infra(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/infra >> >> >> >> -- >> David Caro >> >> Red Hat S.L. >> Continuous Integration Engineer - EMEA ENG Virtualization R&D >> >> Email: dcaro(a)redhat.com >> Web: www.redhat.com >> RHT Global #: 82-62605 >> >> >> _______________________________________________ >> Infra mailing list >> Infra(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra >> --===============3684310797714043661==-- From alonbl at redhat.com Wed Mar 12 11:57:33 2014 Content-Type: multipart/mixed; boundary="===============7174165210908320276==" MIME-Version: 1.0 From: Alon Bar-Lev To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 11:57:13 -0400 Message-ID: <550503996.9291511.1394639833404.JavaMail.zimbra@redhat.com> In-Reply-To: 532082B9.3050400@redhat.com --===============7174165210908320276== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Itamar Heim" > To: "Eli Mesika" , users(a)ovirt.org > Cc: "Maor Lipchuk" , "Tomasz Ko=C5=82ek" , "infra" > Sent: Wednesday, March 12, 2014 5:52:25 PM > Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > = > On 03/12/2014 04:57 PM, Eli Mesika wrote: > > > > > > ----- Original Message ----- > >> From: "David Caro" > >> To: "Itamar Heim" > >> Cc: "Maor Lipchuk" , users(a)ovirt.org, "Tomasz= Ko=C5=82ek" > >> , "infra" > >> > >> Sent: Wednesday, March 12, 2014 11:01:21 AM > >> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > >> > >> On Wed 12 Mar 2014 08:16:02 AM CET, Itamar Heim wrote: > >>> On 03/11/2014 10:08 PM, Maor Lipchuk wrote: > >>>> On 03/11/2014 05:20 PM, Itamar Heim wrote: > >>>>> On 03/11/2014 05:14 PM, Eyal Edri wrote: > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Itamar Heim" > >>>>>>> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" > >>>>>>> , users(a)ovirt.org, "infra" > >>>>>>> Sent: Tuesday, March 11, 2014 5:10:54 PM > >>>>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - > >>>>>>> questions > >>>>>>> > >>>>>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: > >>>>>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: > >>>>>>>>>> Tomasz Ko=C5=82ek wrote: > >>>>>>>>>> > >>>>>>>>>> I've got a few questions about project description. > >>>>>>>>>> Please tell me if my problem's understanding is good or not. > >>>>>>>>>> We need to add a few flags/methods to git review module. This > >>>>>>>>>> flags > >>>>>>>>>> should > >>>>>>>>>> allow to add potential reviewers in gerrit. > >>>>>>>>>> So: > >>>>>>>>>> Let's assume that we've got special flags for this operations. > >>>>>>>>>> What's > >>>>>>>>>> next? > >>>>>>>>>> 1. In gerrit system we need to add special place for potential > >>>>>>>>>> reviewers? > >>>>>>>>>> 2. Potential reviewers should agree that they want to review? > >>>>>>>>>> 3. We can have more than one accepted reviewer? > >>>>>>>>> > >>>>>>>>> I'm not sure i understood exactly what you mean by 'potential > >>>>>>>>> reviewers'. do want gerrit (hook?) to automatically add review= ers > >>>>>>>>> to > >>>>>>>>> a patch according to the code sent? so in fact you'll have a p= lace > >>>>>>>>> somewhere for mapping code & specific developers? > >>>>>>>> > >>>>>>>> I really like this idea. Gerrit currently requires new users to = know > >>>>>>>> who > >>>>>>>> to add as reviewers, IMHO impeding new contributors. > >>>>>>>> > >>>>>>>> One relative simple solution would be to look at who recently > >>>>>>>> touched > >>>>>>>> the files that are being modified and add them as reviewers. This > >>>>>>>> can be > >>>>>>>> done by looking at the git log for a file. Some pseudo python co= de > >>>>>>>> solution: > >>>>>>>> > >>>>>>>> reviewers =3D set() > >>>>>>>> > >>>>>>>> for modified_file in commit.files: > >>>>>>>> reviewers +=3D set(commit.author for commit in > >>>>>>>> git.log(modified_file)) > >>>>>>>> > >>>>>>>> return reviewers > >>>>>>>> > >>>>>>>> This gives a system that those who touche a file, become the > >>>>>>>> maintainer > >>>>>>>> for that file. A more complex solution could improve on that and > >>>>>>>> limit > >>>>>>>> the reviewers added per patch. One can think of limiting to only > >>>>>>>> contributions in the last X months, weigh contributions so common > >>>>>>>> committers are prefered. It could also combine several methods. > >>>>>>>> > >>>>>>>> For example to limit to the 5 authors who touched the most files: > >>>>>>>> > >>>>>>>> reviewers =3D collections.Counter() # New in python 2.7 > >>>>>>>> > >>>>>>>> for modified_file in commit.files: > >>>>>>>> reviewers +=3D collections.Counter(commit.author for com= mit in > >>>>>>>> git.log(modified_file)) > >>>>>>>> > >>>>>>>> return [author for author, count in reviewers.most_common(5)] > >>>>>>>> > >>>>>>>> Since Counter also accepts a dictionary, one could also weigh the > >>>>>>>> touched lines per file. Downside there is big whitespace/formatt= ing > >>>>>>>> patches can skew the line count. > >>>>>>>> > >>>>>>>> In short, I think an entire thesis could be written on the optim= al > >>>>>>>> way > >>>>>>>> to determine reviewers but a simple algorithm could do to show t= he > >>>>>>>> method works. > >>>>>>>> > >>>>>>>> Does this help? > > > > Maybe it will be worth to use the information we have in Bugzilla here: > > > > We can browse the BZ that were closed/verified in the last XXX days > > Per BZ , we know which patches are involved, who reviewed the patches, > > which files were changed, when files were changed and the rank of the > > change (number of lines changed) > > I believe that from this information we can compose a simple ranking > > algorithm that its output will be a list of N potential reviewers for t= he > > patch. > > Since we can aggregate the above information for all files related to t= he > > patch we want to add reviewers, we can have this set for the whole patc= h. > > This information should be processed and stored each N days and gerrit = will > > be able to use it. > = > why are we trying to invent hueristics, instead of declaring clear > ownership? Reminder: my source metadata plan that requires cooperation. Each source and component should have an explicit ownership up into bug dat= abase. I won't repeat it now, it is available at archives. > = > > > > > >>>>>>>> _______________________________________________ > >>>>>>>> Users mailing list > >>>>>>>> Users(a)ovirt.org > >>>>>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>>>>> > >>>>>>> > >>>>>>> I think if we do this, we want to make sure we cover per file who= is > >>>>>>> required to +2 it before we consider it acked. > >>>>>>> > >>>>>> > >>>>>> won't it require maintaining static lists of people per > >>>>>> file/path/project? > >>>>>> > >>>>> > >>>>> yes, but considering our project layout, i don't see an alternative. > >>>>> (some of the layout could be improved to be path based, rather than > >>>>> file > >>>>> based) > >>>> I think it could be done automatically by analysing the file and see= who > >>>> mostly changed it recently, since the "owner" of the file might be > >>>> dynamic, who ever changed most of it few days ago might be more fami= liar > >>>> with it today > >>>> > >>>> IMO the algorithm of adding the reviewers should be flexible. > >>>> For example, using a folder which will contain files, where each file > >>>> implement an algorithm to add the reviewers. > >>>> > >>>> for instance we can have two files: > >>>> 1. Add a reviewers by blame - the contributor which changed recently= the > >>>> code lines > >>>> 2. Add a reviewers by file - the contributor who changed most of the > >>>> file recently. > >>>> > >>>> Each file will implement the functional operation and will output the > >>>> reviewers emails. > >>>> > >>>> The user can then add a new algorithm or change it to be more specif= ic > >>>> to its project. > >>>> for example the user can add also the maintainers which acked the pa= tch > >>>> that was blamed. > >>>>> _______________________________________________ > >>>>> Users mailing list > >>>>> Users(a)ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>> > >>> > >>> this shouldn't be automatic. we need to clearly define ownership. we > >>> can't > >>> do > >>> this per repo for the engine/vdsm. we can do this per repo for the ot= her > >>> repo's probably (though solving the folder/file approach would cover = the > >>> simpler repos as a private case). > >>> > >>> yes, it will require some work, maybe some moving around of files to = make > >>> this > >>> easier by folders (topics) which should be relevant anyway. > >> > >> I think it would easier to maintain if we just have one file at the > >> root, instead of having the ownership information distributed > >> throughout the files/directories. That way you'll know where to look at > >> to check/modify the ownership as opposed to having to walk all the > >> files and upper directories. > >> > >> Also, adding all that ownership logic to gerrit might not be easy, as > >> it's not meant to go checking the source of the repositories looking > >> for configuration. We might want to take a look (again) to zuul, the > >> tool that openstack uses as gateway to trigger jenkins jobs and merge > >> patches. > >> > >>> _______________________________________________ > >>> Infra mailing list > >>> Infra(a)ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/infra > >> > >> > >> > >> -- > >> David Caro > >> > >> Red Hat S.L. > >> Continuous Integration Engineer - EMEA ENG Virtualization R&D > >> > >> Email: dcaro(a)redhat.com > >> Web: www.redhat.com > >> RHT Global #: 82-62605 > >> > >> > >> _______________________________________________ > >> Infra mailing list > >> Infra(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/infra > >> > = > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra >=20 --===============7174165210908320276==-- From mlipchuk at redhat.com Wed Mar 12 13:30:00 2014 Content-Type: multipart/mixed; boundary="===============6617270068082732736==" MIME-Version: 1.0 From: Maor Lipchuk To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 19:29:40 +0200 Message-ID: <53209984.8080402@redhat.com> In-Reply-To: 550503996.9291511.1394639833404.JavaMail.zimbra@redhat.com --===============6617270068082732736== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/12/2014 05:57 PM, Alon Bar-Lev wrote: > = > = > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Eli Mesika" , users(a)ovirt.org >> Cc: "Maor Lipchuk" , "Tomasz Ko=C5=82ek" , "infra" >> Sent: Wednesday, March 12, 2014 5:52:25 PM >> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions >> >> On 03/12/2014 04:57 PM, Eli Mesika wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "David Caro" >>>> To: "Itamar Heim" >>>> Cc: "Maor Lipchuk" , users(a)ovirt.org, "Tomasz= Ko=C5=82ek" >>>> , "infra" >>>> >>>> Sent: Wednesday, March 12, 2014 11:01:21 AM >>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions >>>> >>>> On Wed 12 Mar 2014 08:16:02 AM CET, Itamar Heim wrote: >>>>> On 03/11/2014 10:08 PM, Maor Lipchuk wrote: >>>>>> On 03/11/2014 05:20 PM, Itamar Heim wrote: >>>>>>> On 03/11/2014 05:14 PM, Eyal Edri wrote: >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Itamar Heim" >>>>>>>>> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" >>>>>>>>> , users(a)ovirt.org, "infra" >>>>>>>>> Sent: Tuesday, March 11, 2014 5:10:54 PM >>>>>>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - >>>>>>>>> questions >>>>>>>>> >>>>>>>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: >>>>>>>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: >>>>>>>>>>>> Tomasz Ko=C5=82ek wrote: >>>>>>>>>>>> >>>>>>>>>>>> I've got a few questions about project description. >>>>>>>>>>>> Please tell me if my problem's understanding is good or not. >>>>>>>>>>>> We need to add a few flags/methods to git review module. This >>>>>>>>>>>> flags >>>>>>>>>>>> should >>>>>>>>>>>> allow to add potential reviewers in gerrit. >>>>>>>>>>>> So: >>>>>>>>>>>> Let's assume that we've got special flags for this operations. >>>>>>>>>>>> What's >>>>>>>>>>>> next? >>>>>>>>>>>> 1. In gerrit system we need to add special place for potential >>>>>>>>>>>> reviewers? >>>>>>>>>>>> 2. Potential reviewers should agree that they want to review? >>>>>>>>>>>> 3. We can have more than one accepted reviewer? >>>>>>>>>>> >>>>>>>>>>> I'm not sure i understood exactly what you mean by 'potential >>>>>>>>>>> reviewers'. do want gerrit (hook?) to automatically add review= ers >>>>>>>>>>> to >>>>>>>>>>> a patch according to the code sent? so in fact you'll have a p= lace >>>>>>>>>>> somewhere for mapping code & specific developers? >>>>>>>>>> >>>>>>>>>> I really like this idea. Gerrit currently requires new users to = know >>>>>>>>>> who >>>>>>>>>> to add as reviewers, IMHO impeding new contributors. >>>>>>>>>> >>>>>>>>>> One relative simple solution would be to look at who recently >>>>>>>>>> touched >>>>>>>>>> the files that are being modified and add them as reviewers. This >>>>>>>>>> can be >>>>>>>>>> done by looking at the git log for a file. Some pseudo python co= de >>>>>>>>>> solution: >>>>>>>>>> >>>>>>>>>> reviewers =3D set() >>>>>>>>>> >>>>>>>>>> for modified_file in commit.files: >>>>>>>>>> reviewers +=3D set(commit.author for commit in >>>>>>>>>> git.log(modified_file)) >>>>>>>>>> >>>>>>>>>> return reviewers >>>>>>>>>> >>>>>>>>>> This gives a system that those who touche a file, become the >>>>>>>>>> maintainer >>>>>>>>>> for that file. A more complex solution could improve on that and >>>>>>>>>> limit >>>>>>>>>> the reviewers added per patch. One can think of limiting to only >>>>>>>>>> contributions in the last X months, weigh contributions so common >>>>>>>>>> committers are prefered. It could also combine several methods. >>>>>>>>>> >>>>>>>>>> For example to limit to the 5 authors who touched the most files: >>>>>>>>>> >>>>>>>>>> reviewers =3D collections.Counter() # New in python 2.7 >>>>>>>>>> >>>>>>>>>> for modified_file in commit.files: >>>>>>>>>> reviewers +=3D collections.Counter(commit.author for com= mit in >>>>>>>>>> git.log(modified_file)) >>>>>>>>>> >>>>>>>>>> return [author for author, count in reviewers.most_common(5)] >>>>>>>>>> >>>>>>>>>> Since Counter also accepts a dictionary, one could also weigh the >>>>>>>>>> touched lines per file. Downside there is big whitespace/formatt= ing >>>>>>>>>> patches can skew the line count. >>>>>>>>>> >>>>>>>>>> In short, I think an entire thesis could be written on the optim= al >>>>>>>>>> way >>>>>>>>>> to determine reviewers but a simple algorithm could do to show t= he >>>>>>>>>> method works. >>>>>>>>>> >>>>>>>>>> Does this help? >>> >>> Maybe it will be worth to use the information we have in Bugzilla here: >>> >>> We can browse the BZ that were closed/verified in the last XXX days >>> Per BZ , we know which patches are involved, who reviewed the patches, >>> which files were changed, when files were changed and the rank of the >>> change (number of lines changed) >>> I believe that from this information we can compose a simple ranking >>> algorithm that its output will be a list of N potential reviewers for t= he >>> patch. >>> Since we can aggregate the above information for all files related to t= he >>> patch we want to add reviewers, we can have this set for the whole patc= h. >>> This information should be processed and stored each N days and gerrit = will >>> be able to use it. >> >> why are we trying to invent hueristics, instead of declaring clear >> ownership? > = > Reminder: my source metadata plan that requires cooperation. > = > Each source and component should have an explicit ownership up into bug d= atabase. > = > I won't repeat it now, it is available at archives. > = I think we are discussing two different issues here: The first one considers the GSOC project, of adding reviewers automatically to a patch, this can be done in many different heuristics depending what the submitter prefers (use blame, maintainers who acked the patches, bugs, list of owners to a file and so on). The second issue is adding and maintain a list of owners by files/folders in oVirt. this is a specific use case to be used by the "add potential reviewers" project. >> >>> >>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Users mailing list >>>>>>>>>> Users(a)ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think if we do this, we want to make sure we cover per file who= is >>>>>>>>> required to +2 it before we consider it acked. >>>>>>>>> >>>>>>>> >>>>>>>> won't it require maintaining static lists of people per >>>>>>>> file/path/project? >>>>>>>> >>>>>>> >>>>>>> yes, but considering our project layout, i don't see an alternative. >>>>>>> (some of the layout could be improved to be path based, rather than >>>>>>> file >>>>>>> based) >>>>>> I think it could be done automatically by analysing the file and see= who >>>>>> mostly changed it recently, since the "owner" of the file might be >>>>>> dynamic, who ever changed most of it few days ago might be more fami= liar >>>>>> with it today >>>>>> >>>>>> IMO the algorithm of adding the reviewers should be flexible. >>>>>> For example, using a folder which will contain files, where each file >>>>>> implement an algorithm to add the reviewers. >>>>>> >>>>>> for instance we can have two files: >>>>>> 1. Add a reviewers by blame - the contributor which changed recently= the >>>>>> code lines >>>>>> 2. Add a reviewers by file - the contributor who changed most of the >>>>>> file recently. >>>>>> >>>>>> Each file will implement the functional operation and will output the >>>>>> reviewers emails. >>>>>> >>>>>> The user can then add a new algorithm or change it to be more specif= ic >>>>>> to its project. >>>>>> for example the user can add also the maintainers which acked the pa= tch >>>>>> that was blamed. >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>> >>>>> >>>>> this shouldn't be automatic. we need to clearly define ownership. we >>>>> can't >>>>> do >>>>> this per repo for the engine/vdsm. we can do this per repo for the ot= her >>>>> repo's probably (though solving the folder/file approach would cover = the >>>>> simpler repos as a private case). >>>>> >>>>> yes, it will require some work, maybe some moving around of files to = make >>>>> this >>>>> easier by folders (topics) which should be relevant anyway. >>>> >>>> I think it would easier to maintain if we just have one file at the >>>> root, instead of having the ownership information distributed >>>> throughout the files/directories. That way you'll know where to look at >>>> to check/modify the ownership as opposed to having to walk all the >>>> files and upper directories. >>>> >>>> Also, adding all that ownership logic to gerrit might not be easy, as >>>> it's not meant to go checking the source of the repositories looking >>>> for configuration. We might want to take a look (again) to zuul, the >>>> tool that openstack uses as gateway to trigger jenkins jobs and merge >>>> patches. >>>> >>>>> _______________________________________________ >>>>> Infra mailing list >>>>> Infra(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>> >>>> >>>> >>>> -- >>>> David Caro >>>> >>>> Red Hat S.L. >>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D >>>> >>>> Email: dcaro(a)redhat.com >>>> Web: www.redhat.com >>>> RHT Global #: 82-62605 >>>> >>>> >>>> _______________________________________________ >>>> Infra mailing list >>>> Infra(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/infra >>>> >> >> _______________________________________________ >> Infra mailing list >> Infra(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra >> --===============6617270068082732736==-- From alonbl at redhat.com Wed Mar 12 13:33:05 2014 Content-Type: multipart/mixed; boundary="===============2677002182350207238==" MIME-Version: 1.0 From: Alon Bar-Lev To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 13:32:47 -0400 Message-ID: <911731785.9329634.1394645567140.JavaMail.zimbra@redhat.com> In-Reply-To: 53209984.8080402@redhat.com --===============2677002182350207238== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Maor Lipchuk" > To: "Alon Bar-Lev" , "Itamar Heim" > Cc: "Eli Mesika" , users(a)ovirt.org, "Tomasz Ko=C5= =82ek" , "infra" > > Sent: Wednesday, March 12, 2014 7:29:40 PM > Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > = > On 03/12/2014 05:57 PM, Alon Bar-Lev wrote: > > = > > = > > ----- Original Message ----- > >> From: "Itamar Heim" > >> To: "Eli Mesika" , users(a)ovirt.org > >> Cc: "Maor Lipchuk" , "Tomasz Ko=C5=82ek" > >> , "infra" > >> Sent: Wednesday, March 12, 2014 5:52:25 PM > >> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > >> > >> On 03/12/2014 04:57 PM, Eli Mesika wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "David Caro" > >>>> To: "Itamar Heim" > >>>> Cc: "Maor Lipchuk" , users(a)ovirt.org, "Toma= sz > >>>> Ko=C5=82ek" > >>>> , "infra" > >>>> > >>>> Sent: Wednesday, March 12, 2014 11:01:21 AM > >>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questi= ons > >>>> > >>>> On Wed 12 Mar 2014 08:16:02 AM CET, Itamar Heim wrote: > >>>>> On 03/11/2014 10:08 PM, Maor Lipchuk wrote: > >>>>>> On 03/11/2014 05:20 PM, Itamar Heim wrote: > >>>>>>> On 03/11/2014 05:14 PM, Eyal Edri wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>>> From: "Itamar Heim" > >>>>>>>>> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" > >>>>>>>>> , users(a)ovirt.org, "infra" > >>>>>>>>> Sent: Tuesday, March 11, 2014 5:10:54 PM > >>>>>>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - > >>>>>>>>> questions > >>>>>>>>> > >>>>>>>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: > >>>>>>>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: > >>>>>>>>>>>> Tomasz Ko=C5=82ek wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> I've got a few questions about project description. > >>>>>>>>>>>> Please tell me if my problem's understanding is good or not. > >>>>>>>>>>>> We need to add a few flags/methods to git review module. This > >>>>>>>>>>>> flags > >>>>>>>>>>>> should > >>>>>>>>>>>> allow to add potential reviewers in gerrit. > >>>>>>>>>>>> So: > >>>>>>>>>>>> Let's assume that we've got special flags for this operation= s. > >>>>>>>>>>>> What's > >>>>>>>>>>>> next? > >>>>>>>>>>>> 1. In gerrit system we need to add special place for potenti= al > >>>>>>>>>>>> reviewers? > >>>>>>>>>>>> 2. Potential reviewers should agree that they want to review? > >>>>>>>>>>>> 3. We can have more than one accepted reviewer? > >>>>>>>>>>> > >>>>>>>>>>> I'm not sure i understood exactly what you mean by 'potential > >>>>>>>>>>> reviewers'. do want gerrit (hook?) to automatically add > >>>>>>>>>>> reviewers > >>>>>>>>>>> to > >>>>>>>>>>> a patch according to the code sent? so in fact you'll have a > >>>>>>>>>>> place > >>>>>>>>>>> somewhere for mapping code & specific developers? > >>>>>>>>>> > >>>>>>>>>> I really like this idea. Gerrit currently requires new users to > >>>>>>>>>> know > >>>>>>>>>> who > >>>>>>>>>> to add as reviewers, IMHO impeding new contributors. > >>>>>>>>>> > >>>>>>>>>> One relative simple solution would be to look at who recently > >>>>>>>>>> touched > >>>>>>>>>> the files that are being modified and add them as reviewers. T= his > >>>>>>>>>> can be > >>>>>>>>>> done by looking at the git log for a file. Some pseudo python = code > >>>>>>>>>> solution: > >>>>>>>>>> > >>>>>>>>>> reviewers =3D set() > >>>>>>>>>> > >>>>>>>>>> for modified_file in commit.files: > >>>>>>>>>> reviewers +=3D set(commit.author for commit in > >>>>>>>>>> git.log(modified_file)) > >>>>>>>>>> > >>>>>>>>>> return reviewers > >>>>>>>>>> > >>>>>>>>>> This gives a system that those who touche a file, become the > >>>>>>>>>> maintainer > >>>>>>>>>> for that file. A more complex solution could improve on that a= nd > >>>>>>>>>> limit > >>>>>>>>>> the reviewers added per patch. One can think of limiting to on= ly > >>>>>>>>>> contributions in the last X months, weigh contributions so com= mon > >>>>>>>>>> committers are prefered. It could also combine several methods. > >>>>>>>>>> > >>>>>>>>>> For example to limit to the 5 authors who touched the most fil= es: > >>>>>>>>>> > >>>>>>>>>> reviewers =3D collections.Counter() # New in python 2.7 > >>>>>>>>>> > >>>>>>>>>> for modified_file in commit.files: > >>>>>>>>>> reviewers +=3D collections.Counter(commit.author for c= ommit > >>>>>>>>>> in > >>>>>>>>>> git.log(modified_file)) > >>>>>>>>>> > >>>>>>>>>> return [author for author, count in reviewers.most_common(5)] > >>>>>>>>>> > >>>>>>>>>> Since Counter also accepts a dictionary, one could also weigh = the > >>>>>>>>>> touched lines per file. Downside there is big > >>>>>>>>>> whitespace/formatting > >>>>>>>>>> patches can skew the line count. > >>>>>>>>>> > >>>>>>>>>> In short, I think an entire thesis could be written on the opt= imal > >>>>>>>>>> way > >>>>>>>>>> to determine reviewers but a simple algorithm could do to show= the > >>>>>>>>>> method works. > >>>>>>>>>> > >>>>>>>>>> Does this help? > >>> > >>> Maybe it will be worth to use the information we have in Bugzilla her= e: > >>> > >>> We can browse the BZ that were closed/verified in the last XXX days > >>> Per BZ , we know which patches are involved, who reviewed the patches, > >>> which files were changed, when files were changed and the rank of the > >>> change (number of lines changed) > >>> I believe that from this information we can compose a simple ranking > >>> algorithm that its output will be a list of N potential reviewers for= the > >>> patch. > >>> Since we can aggregate the above information for all files related to= the > >>> patch we want to add reviewers, we can have this set for the whole pa= tch. > >>> This information should be processed and stored each N days and gerrit > >>> will > >>> be able to use it. > >> > >> why are we trying to invent hueristics, instead of declaring clear > >> ownership? > > = > > Reminder: my source metadata plan that requires cooperation. > > = > > Each source and component should have an explicit ownership up into bug > > database. > > = > > I won't repeat it now, it is available at archives. > > = > I think we are discussing two different issues here: > The first one considers the GSOC project, of adding reviewers > automatically to a patch, this can be done in many different heuristics > depending what the submitter prefers (use blame, maintainers who acked > the patches, bugs, list of owners to a file and so on). > = > The second issue is adding and maintain a list of owners by > files/folders in oVirt. > this is a specific use case to be used by the "add potential reviewers" > project. There is no such think as "reviewer" there is component maintainer. Random reviewers are irrelevant. Each GSOC participate should have a mentor, this mentor should be the maint= ainer of the relevant component. The mentor is responsible for the process, while the participate is providi= ng the technical work. > = > >> > >>> > >>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Users mailing list > >>>>>>>>>> Users(a)ovirt.org > >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> I think if we do this, we want to make sure we cover per file w= ho > >>>>>>>>> is > >>>>>>>>> required to +2 it before we consider it acked. > >>>>>>>>> > >>>>>>>> > >>>>>>>> won't it require maintaining static lists of people per > >>>>>>>> file/path/project? > >>>>>>>> > >>>>>>> > >>>>>>> yes, but considering our project layout, i don't see an alternati= ve. > >>>>>>> (some of the layout could be improved to be path based, rather th= an > >>>>>>> file > >>>>>>> based) > >>>>>> I think it could be done automatically by analysing the file and s= ee > >>>>>> who > >>>>>> mostly changed it recently, since the "owner" of the file might be > >>>>>> dynamic, who ever changed most of it few days ago might be more > >>>>>> familiar > >>>>>> with it today > >>>>>> > >>>>>> IMO the algorithm of adding the reviewers should be flexible. > >>>>>> For example, using a folder which will contain files, where each f= ile > >>>>>> implement an algorithm to add the reviewers. > >>>>>> > >>>>>> for instance we can have two files: > >>>>>> 1. Add a reviewers by blame - the contributor which changed recent= ly > >>>>>> the > >>>>>> code lines > >>>>>> 2. Add a reviewers by file - the contributor who changed most of t= he > >>>>>> file recently. > >>>>>> > >>>>>> Each file will implement the functional operation and will output = the > >>>>>> reviewers emails. > >>>>>> > >>>>>> The user can then add a new algorithm or change it to be more spec= ific > >>>>>> to its project. > >>>>>> for example the user can add also the maintainers which acked the > >>>>>> patch > >>>>>> that was blamed. > >>>>>>> _______________________________________________ > >>>>>>> Users mailing list > >>>>>>> Users(a)ovirt.org > >>>>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>>> > >>>>> > >>>>> this shouldn't be automatic. we need to clearly define ownership. we > >>>>> can't > >>>>> do > >>>>> this per repo for the engine/vdsm. we can do this per repo for the > >>>>> other > >>>>> repo's probably (though solving the folder/file approach would cover > >>>>> the > >>>>> simpler repos as a private case). > >>>>> > >>>>> yes, it will require some work, maybe some moving around of files to > >>>>> make > >>>>> this > >>>>> easier by folders (topics) which should be relevant anyway. > >>>> > >>>> I think it would easier to maintain if we just have one file at the > >>>> root, instead of having the ownership information distributed > >>>> throughout the files/directories. That way you'll know where to look= at > >>>> to check/modify the ownership as opposed to having to walk all the > >>>> files and upper directories. > >>>> > >>>> Also, adding all that ownership logic to gerrit might not be easy, as > >>>> it's not meant to go checking the source of the repositories looking > >>>> for configuration. We might want to take a look (again) to zuul, the > >>>> tool that openstack uses as gateway to trigger jenkins jobs and merge > >>>> patches. > >>>> > >>>>> _______________________________________________ > >>>>> Infra mailing list > >>>>> Infra(a)ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/infra > >>>> > >>>> > >>>> > >>>> -- > >>>> David Caro > >>>> > >>>> Red Hat S.L. > >>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D > >>>> > >>>> Email: dcaro(a)redhat.com > >>>> Web: www.redhat.com > >>>> RHT Global #: 82-62605 > >>>> > >>>> > >>>> _______________________________________________ > >>>> Infra mailing list > >>>> Infra(a)ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/infra > >>>> > >> > >> _______________________________________________ > >> Infra mailing list > >> Infra(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/infra > >> > = >=20 --===============2677002182350207238==-- From iheim at redhat.com Wed Mar 12 15:30:02 2014 Content-Type: multipart/mixed; boundary="===============7817587971826607113==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 21:29:28 +0200 Message-ID: <5320B598.90502@redhat.com> In-Reply-To: 53209984.8080402@redhat.com --===============7817587971826607113== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/12/2014 07:29 PM, Maor Lipchuk wrote: > On 03/12/2014 05:57 PM, Alon Bar-Lev wrote: >> >> >> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Eli Mesika" , users(a)ovirt.org >>> Cc: "Maor Lipchuk" , "Tomasz Ko=C5=82ek" , "infra" >>> Sent: Wednesday, March 12, 2014 5:52:25 PM >>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions >>> >>> On 03/12/2014 04:57 PM, Eli Mesika wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "David Caro" >>>>> To: "Itamar Heim" >>>>> Cc: "Maor Lipchuk" , users(a)ovirt.org, "Tomas= z Ko=C5=82ek" >>>>> , "infra" >>>>> >>>>> Sent: Wednesday, March 12, 2014 11:01:21 AM >>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questio= ns >>>>> >>>>> On Wed 12 Mar 2014 08:16:02 AM CET, Itamar Heim wrote: >>>>>> On 03/11/2014 10:08 PM, Maor Lipchuk wrote: >>>>>>> On 03/11/2014 05:20 PM, Itamar Heim wrote: >>>>>>>> On 03/11/2014 05:14 PM, Eyal Edri wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "Itamar Heim" >>>>>>>>>> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" >>>>>>>>>> , users(a)ovirt.org, "infra" >>>>>>>>>> Sent: Tuesday, March 11, 2014 5:10:54 PM >>>>>>>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - >>>>>>>>>> questions >>>>>>>>>> >>>>>>>>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: >>>>>>>>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: >>>>>>>>>>>>> Tomasz Ko=C5=82ek wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I've got a few questions about project description. >>>>>>>>>>>>> Please tell me if my problem's understanding is good or not. >>>>>>>>>>>>> We need to add a few flags/methods to git review module. This >>>>>>>>>>>>> flags >>>>>>>>>>>>> should >>>>>>>>>>>>> allow to add potential reviewers in gerrit. >>>>>>>>>>>>> So: >>>>>>>>>>>>> Let's assume that we've got special flags for this operations. >>>>>>>>>>>>> What's >>>>>>>>>>>>> next? >>>>>>>>>>>>> 1. In gerrit system we need to add special place for potential >>>>>>>>>>>>> reviewers? >>>>>>>>>>>>> 2. Potential reviewers should agree that they want to review? >>>>>>>>>>>>> 3. We can have more than one accepted reviewer? >>>>>>>>>>>> >>>>>>>>>>>> I'm not sure i understood exactly what you mean by 'potential >>>>>>>>>>>> reviewers'. do want gerrit (hook?) to automatically add revie= wers >>>>>>>>>>>> to >>>>>>>>>>>> a patch according to the code sent? so in fact you'll have a = place >>>>>>>>>>>> somewhere for mapping code & specific developers? >>>>>>>>>>> >>>>>>>>>>> I really like this idea. Gerrit currently requires new users to= know >>>>>>>>>>> who >>>>>>>>>>> to add as reviewers, IMHO impeding new contributors. >>>>>>>>>>> >>>>>>>>>>> One relative simple solution would be to look at who recently >>>>>>>>>>> touched >>>>>>>>>>> the files that are being modified and add them as reviewers. Th= is >>>>>>>>>>> can be >>>>>>>>>>> done by looking at the git log for a file. Some pseudo python c= ode >>>>>>>>>>> solution: >>>>>>>>>>> >>>>>>>>>>> reviewers =3D set() >>>>>>>>>>> >>>>>>>>>>> for modified_file in commit.files: >>>>>>>>>>> reviewers +=3D set(commit.author for commit in >>>>>>>>>>> git.log(modified_file)) >>>>>>>>>>> >>>>>>>>>>> return reviewers >>>>>>>>>>> >>>>>>>>>>> This gives a system that those who touche a file, become the >>>>>>>>>>> maintainer >>>>>>>>>>> for that file. A more complex solution could improve on that and >>>>>>>>>>> limit >>>>>>>>>>> the reviewers added per patch. One can think of limiting to only >>>>>>>>>>> contributions in the last X months, weigh contributions so comm= on >>>>>>>>>>> committers are prefered. It could also combine several methods. >>>>>>>>>>> >>>>>>>>>>> For example to limit to the 5 authors who touched the most file= s: >>>>>>>>>>> >>>>>>>>>>> reviewers =3D collections.Counter() # New in python 2.7 >>>>>>>>>>> >>>>>>>>>>> for modified_file in commit.files: >>>>>>>>>>> reviewers +=3D collections.Counter(commit.author for c= ommit in >>>>>>>>>>> git.log(modified_file)) >>>>>>>>>>> >>>>>>>>>>> return [author for author, count in reviewers.most_common(5)] >>>>>>>>>>> >>>>>>>>>>> Since Counter also accepts a dictionary, one could also weigh t= he >>>>>>>>>>> touched lines per file. Downside there is big whitespace/format= ting >>>>>>>>>>> patches can skew the line count. >>>>>>>>>>> >>>>>>>>>>> In short, I think an entire thesis could be written on the opti= mal >>>>>>>>>>> way >>>>>>>>>>> to determine reviewers but a simple algorithm could do to show = the >>>>>>>>>>> method works. >>>>>>>>>>> >>>>>>>>>>> Does this help? >>>> >>>> Maybe it will be worth to use the information we have in Bugzilla here: >>>> >>>> We can browse the BZ that were closed/verified in the last XXX days >>>> Per BZ , we know which patches are involved, who reviewed the patches, >>>> which files were changed, when files were changed and the rank of the >>>> change (number of lines changed) >>>> I believe that from this information we can compose a simple ranking >>>> algorithm that its output will be a list of N potential reviewers for = the >>>> patch. >>>> Since we can aggregate the above information for all files related to = the >>>> patch we want to add reviewers, we can have this set for the whole pat= ch. >>>> This information should be processed and stored each N days and gerrit= will >>>> be able to use it. >>> >>> why are we trying to invent hueristics, instead of declaring clear >>> ownership? >> >> Reminder: my source metadata plan that requires cooperation. >> >> Each source and component should have an explicit ownership up into bug = database. >> >> I won't repeat it now, it is available at archives. >> > I think we are discussing two different issues here: > The first one considers the GSOC project, of adding reviewers > automatically to a patch, this can be done in many different heuristics > depending what the submitter prefers (use blame, maintainers who acked > the patches, bugs, list of owners to a file and so on). that's the point. we should be using heuristics, rather ownership. this could still be done via a GSOC project for implementing the gerrit = logic to do so. > > The second issue is adding and maintain a list of owners by > files/folders in oVirt. > this is a specific use case to be used by the "add potential reviewers" > project. > >>> >>>> >>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Users mailing list >>>>>>>>>>> Users(a)ovirt.org >>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think if we do this, we want to make sure we cover per file wh= o is >>>>>>>>>> required to +2 it before we consider it acked. >>>>>>>>>> >>>>>>>>> >>>>>>>>> won't it require maintaining static lists of people per >>>>>>>>> file/path/project? >>>>>>>>> >>>>>>>> >>>>>>>> yes, but considering our project layout, i don't see an alternativ= e. >>>>>>>> (some of the layout could be improved to be path based, rather than >>>>>>>> file >>>>>>>> based) >>>>>>> I think it could be done automatically by analysing the file and se= e who >>>>>>> mostly changed it recently, since the "owner" of the file might be >>>>>>> dynamic, who ever changed most of it few days ago might be more fam= iliar >>>>>>> with it today >>>>>>> >>>>>>> IMO the algorithm of adding the reviewers should be flexible. >>>>>>> For example, using a folder which will contain files, where each fi= le >>>>>>> implement an algorithm to add the reviewers. >>>>>>> >>>>>>> for instance we can have two files: >>>>>>> 1. Add a reviewers by blame - the contributor which changed recentl= y the >>>>>>> code lines >>>>>>> 2. Add a reviewers by file - the contributor who changed most of the >>>>>>> file recently. >>>>>>> >>>>>>> Each file will implement the functional operation and will output t= he >>>>>>> reviewers emails. >>>>>>> >>>>>>> The user can then add a new algorithm or change it to be more speci= fic >>>>>>> to its project. >>>>>>> for example the user can add also the maintainers which acked the p= atch >>>>>>> that was blamed. >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users(a)ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>>> >>>>>> >>>>>> this shouldn't be automatic. we need to clearly define ownership. we >>>>>> can't >>>>>> do >>>>>> this per repo for the engine/vdsm. we can do this per repo for the o= ther >>>>>> repo's probably (though solving the folder/file approach would cover= the >>>>>> simpler repos as a private case). >>>>>> >>>>>> yes, it will require some work, maybe some moving around of files to= make >>>>>> this >>>>>> easier by folders (topics) which should be relevant anyway. >>>>> >>>>> I think it would easier to maintain if we just have one file at the >>>>> root, instead of having the ownership information distributed >>>>> throughout the files/directories. That way you'll know where to look = at >>>>> to check/modify the ownership as opposed to having to walk all the >>>>> files and upper directories. >>>>> >>>>> Also, adding all that ownership logic to gerrit might not be easy, as >>>>> it's not meant to go checking the source of the repositories looking >>>>> for configuration. We might want to take a look (again) to zuul, the >>>>> tool that openstack uses as gateway to trigger jenkins jobs and merge >>>>> patches. >>>>> >>>>>> _______________________________________________ >>>>>> Infra mailing list >>>>>> Infra(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>> >>>>> >>>>> >>>>> -- >>>>> David Caro >>>>> >>>>> Red Hat S.L. >>>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D >>>>> >>>>> Email: dcaro(a)redhat.com >>>>> Web: www.redhat.com >>>>> RHT Global #: 82-62605 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Infra mailing list >>>>> Infra(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>> >>> >>> _______________________________________________ >>> Infra mailing list >>> Infra(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/infra >>> > --===============7817587971826607113==-- From alonbl at redhat.com Wed Mar 12 15:42:27 2014 Content-Type: multipart/mixed; boundary="===============6730054637830136157==" MIME-Version: 1.0 From: Alon Bar-Lev To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 15:42:00 -0400 Message-ID: <1458628516.9374414.1394653320030.JavaMail.zimbra@redhat.com> In-Reply-To: 5320B598.90502@redhat.com --===============6730054637830136157== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Itamar Heim" > To: "Maor Lipchuk" , "Alon Bar-Lev" > Cc: "Eli Mesika" , users(a)ovirt.org, "Tomasz Ko=C5= =82ek" , "infra" > > Sent: Wednesday, March 12, 2014 9:29:28 PM > Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions > = > On 03/12/2014 07:29 PM, Maor Lipchuk wrote: > > On 03/12/2014 05:57 PM, Alon Bar-Lev wrote: > >> > >> > >> ----- Original Message ----- > >>> From: "Itamar Heim" > >>> To: "Eli Mesika" , users(a)ovirt.org > >>> Cc: "Maor Lipchuk" , "Tomasz Ko=C5=82ek" > >>> , "infra" > >>> Sent: Wednesday, March 12, 2014 5:52:25 PM > >>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questio= ns > >>> > >>> On 03/12/2014 04:57 PM, Eli Mesika wrote: > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "David Caro" > >>>>> To: "Itamar Heim" > >>>>> Cc: "Maor Lipchuk" , users(a)ovirt.org, "Tom= asz > >>>>> Ko=C5=82ek" > >>>>> , "infra" > >>>>> > >>>>> Sent: Wednesday, March 12, 2014 11:01:21 AM > >>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - quest= ions > >>>>> > >>>>> On Wed 12 Mar 2014 08:16:02 AM CET, Itamar Heim wrote: > >>>>>> On 03/11/2014 10:08 PM, Maor Lipchuk wrote: > >>>>>>> On 03/11/2014 05:20 PM, Itamar Heim wrote: > >>>>>>>> On 03/11/2014 05:14 PM, Eyal Edri wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ----- Original Message ----- > >>>>>>>>>> From: "Itamar Heim" > >>>>>>>>>> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" > >>>>>>>>>> , users(a)ovirt.org, "infra" > >>>>>>>>>> Sent: Tuesday, March 11, 2014 5:10:54 PM > >>>>>>>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - > >>>>>>>>>> questions > >>>>>>>>>> > >>>>>>>>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: > >>>>>>>>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: > >>>>>>>>>>>>> Tomasz Ko=C5=82ek wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> I've got a few questions about project description. > >>>>>>>>>>>>> Please tell me if my problem's understanding is good or not. > >>>>>>>>>>>>> We need to add a few flags/methods to git review module. Th= is > >>>>>>>>>>>>> flags > >>>>>>>>>>>>> should > >>>>>>>>>>>>> allow to add potential reviewers in gerrit. > >>>>>>>>>>>>> So: > >>>>>>>>>>>>> Let's assume that we've got special flags for this operatio= ns. > >>>>>>>>>>>>> What's > >>>>>>>>>>>>> next? > >>>>>>>>>>>>> 1. In gerrit system we need to add special place for potent= ial > >>>>>>>>>>>>> reviewers? > >>>>>>>>>>>>> 2. Potential reviewers should agree that they want to revie= w? > >>>>>>>>>>>>> 3. We can have more than one accepted reviewer? > >>>>>>>>>>>> > >>>>>>>>>>>> I'm not sure i understood exactly what you mean by 'potential > >>>>>>>>>>>> reviewers'. do want gerrit (hook?) to automatically add > >>>>>>>>>>>> reviewers > >>>>>>>>>>>> to > >>>>>>>>>>>> a patch according to the code sent? so in fact you'll have a > >>>>>>>>>>>> place > >>>>>>>>>>>> somewhere for mapping code & specific developers? > >>>>>>>>>>> > >>>>>>>>>>> I really like this idea. Gerrit currently requires new users = to > >>>>>>>>>>> know > >>>>>>>>>>> who > >>>>>>>>>>> to add as reviewers, IMHO impeding new contributors. > >>>>>>>>>>> > >>>>>>>>>>> One relative simple solution would be to look at who recently > >>>>>>>>>>> touched > >>>>>>>>>>> the files that are being modified and add them as reviewers. = This > >>>>>>>>>>> can be > >>>>>>>>>>> done by looking at the git log for a file. Some pseudo python > >>>>>>>>>>> code > >>>>>>>>>>> solution: > >>>>>>>>>>> > >>>>>>>>>>> reviewers =3D set() > >>>>>>>>>>> > >>>>>>>>>>> for modified_file in commit.files: > >>>>>>>>>>> reviewers +=3D set(commit.author for commit in > >>>>>>>>>>> git.log(modified_file)) > >>>>>>>>>>> > >>>>>>>>>>> return reviewers > >>>>>>>>>>> > >>>>>>>>>>> This gives a system that those who touche a file, become the > >>>>>>>>>>> maintainer > >>>>>>>>>>> for that file. A more complex solution could improve on that = and > >>>>>>>>>>> limit > >>>>>>>>>>> the reviewers added per patch. One can think of limiting to o= nly > >>>>>>>>>>> contributions in the last X months, weigh contributions so co= mmon > >>>>>>>>>>> committers are prefered. It could also combine several method= s. > >>>>>>>>>>> > >>>>>>>>>>> For example to limit to the 5 authors who touched the most fi= les: > >>>>>>>>>>> > >>>>>>>>>>> reviewers =3D collections.Counter() # New in python 2.7 > >>>>>>>>>>> > >>>>>>>>>>> for modified_file in commit.files: > >>>>>>>>>>> reviewers +=3D collections.Counter(commit.author for > >>>>>>>>>>> commit in > >>>>>>>>>>> git.log(modified_file)) > >>>>>>>>>>> > >>>>>>>>>>> return [author for author, count in reviewers.most_common(5)] > >>>>>>>>>>> > >>>>>>>>>>> Since Counter also accepts a dictionary, one could also weigh= the > >>>>>>>>>>> touched lines per file. Downside there is big > >>>>>>>>>>> whitespace/formatting > >>>>>>>>>>> patches can skew the line count. > >>>>>>>>>>> > >>>>>>>>>>> In short, I think an entire thesis could be written on the > >>>>>>>>>>> optimal > >>>>>>>>>>> way > >>>>>>>>>>> to determine reviewers but a simple algorithm could do to show > >>>>>>>>>>> the > >>>>>>>>>>> method works. > >>>>>>>>>>> > >>>>>>>>>>> Does this help? > >>>> > >>>> Maybe it will be worth to use the information we have in Bugzilla he= re: > >>>> > >>>> We can browse the BZ that were closed/verified in the last XXX days > >>>> Per BZ , we know which patches are involved, who reviewed the patche= s, > >>>> which files were changed, when files were changed and the rank of the > >>>> change (number of lines changed) > >>>> I believe that from this information we can compose a simple ranking > >>>> algorithm that its output will be a list of N potential reviewers for > >>>> the > >>>> patch. > >>>> Since we can aggregate the above information for all files related to > >>>> the > >>>> patch we want to add reviewers, we can have this set for the whole > >>>> patch. > >>>> This information should be processed and stored each N days and gerr= it > >>>> will > >>>> be able to use it. > >>> > >>> why are we trying to invent hueristics, instead of declaring clear > >>> ownership? > >> > >> Reminder: my source metadata plan that requires cooperation. > >> > >> Each source and component should have an explicit ownership up into bug > >> database. > >> > >> I won't repeat it now, it is available at archives. > >> > > I think we are discussing two different issues here: > > The first one considers the GSOC project, of adding reviewers > > automatically to a patch, this can be done in many different heuristics > > depending what the submitter prefers (use blame, maintainers who acked > > the patches, bugs, list of owners to a file and so on). > = > that's the point. we should be using heuristics, rather ownership. I want heuristics to solve bugs as well. Maybe for each issue I will use heuristic and wait for X days for someone e= lse to fix? I would like to see how you build a building using heuristic reviews. > this could still be done via a GSOC project for implementing the gerrit > logic to do so. > = > > > > The second issue is adding and maintain a list of owners by > > files/folders in oVirt. > > this is a specific use case to be used by the "add potential reviewers" > > project. > > > >>> > >>>> > >>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Users mailing list > >>>>>>>>>>> Users(a)ovirt.org > >>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I think if we do this, we want to make sure we cover per file = who > >>>>>>>>>> is > >>>>>>>>>> required to +2 it before we consider it acked. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> won't it require maintaining static lists of people per > >>>>>>>>> file/path/project? > >>>>>>>>> > >>>>>>>> > >>>>>>>> yes, but considering our project layout, i don't see an alternat= ive. > >>>>>>>> (some of the layout could be improved to be path based, rather t= han > >>>>>>>> file > >>>>>>>> based) > >>>>>>> I think it could be done automatically by analysing the file and = see > >>>>>>> who > >>>>>>> mostly changed it recently, since the "owner" of the file might be > >>>>>>> dynamic, who ever changed most of it few days ago might be more > >>>>>>> familiar > >>>>>>> with it today > >>>>>>> > >>>>>>> IMO the algorithm of adding the reviewers should be flexible. > >>>>>>> For example, using a folder which will contain files, where each = file > >>>>>>> implement an algorithm to add the reviewers. > >>>>>>> > >>>>>>> for instance we can have two files: > >>>>>>> 1. Add a reviewers by blame - the contributor which changed recen= tly > >>>>>>> the > >>>>>>> code lines > >>>>>>> 2. Add a reviewers by file - the contributor who changed most of = the > >>>>>>> file recently. > >>>>>>> > >>>>>>> Each file will implement the functional operation and will output= the > >>>>>>> reviewers emails. > >>>>>>> > >>>>>>> The user can then add a new algorithm or change it to be more > >>>>>>> specific > >>>>>>> to its project. > >>>>>>> for example the user can add also the maintainers which acked the > >>>>>>> patch > >>>>>>> that was blamed. > >>>>>>>> _______________________________________________ > >>>>>>>> Users mailing list > >>>>>>>> Users(a)ovirt.org > >>>>>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>>>> > >>>>>> > >>>>>> this shouldn't be automatic. we need to clearly define ownership. = we > >>>>>> can't > >>>>>> do > >>>>>> this per repo for the engine/vdsm. we can do this per repo for the > >>>>>> other > >>>>>> repo's probably (though solving the folder/file approach would cov= er > >>>>>> the > >>>>>> simpler repos as a private case). > >>>>>> > >>>>>> yes, it will require some work, maybe some moving around of files = to > >>>>>> make > >>>>>> this > >>>>>> easier by folders (topics) which should be relevant anyway. > >>>>> > >>>>> I think it would easier to maintain if we just have one file at the > >>>>> root, instead of having the ownership information distributed > >>>>> throughout the files/directories. That way you'll know where to loo= k at > >>>>> to check/modify the ownership as opposed to having to walk all the > >>>>> files and upper directories. > >>>>> > >>>>> Also, adding all that ownership logic to gerrit might not be easy, = as > >>>>> it's not meant to go checking the source of the repositories looking > >>>>> for configuration. We might want to take a look (again) to zuul, the > >>>>> tool that openstack uses as gateway to trigger jenkins jobs and mer= ge > >>>>> patches. > >>>>> > >>>>>> _______________________________________________ > >>>>>> Infra mailing list > >>>>>> Infra(a)ovirt.org > >>>>>> http://lists.ovirt.org/mailman/listinfo/infra > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> David Caro > >>>>> > >>>>> Red Hat S.L. > >>>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D > >>>>> > >>>>> Email: dcaro(a)redhat.com > >>>>> Web: www.redhat.com > >>>>> RHT Global #: 82-62605 > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Infra mailing list > >>>>> Infra(a)ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/infra > >>>>> > >>> > >>> _______________________________________________ > >>> Infra mailing list > >>> Infra(a)ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/infra > >>> > > > = >=20 --===============6730054637830136157==-- From iheim at redhat.com Wed Mar 12 15:46:47 2014 Content-Type: multipart/mixed; boundary="===============6998700668829007194==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions Date: Wed, 12 Mar 2014 21:46:00 +0200 Message-ID: <5320B978.5060705@redhat.com> In-Reply-To: 1458628516.9374414.1394653320030.JavaMail.zimbra@redhat.com --===============6998700668829007194== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/12/2014 09:42 PM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Maor Lipchuk" , "Alon Bar-Lev" >> Cc: "Eli Mesika" , users(a)ovirt.org, "Tomasz Ko= =C5=82ek" , "infra" >> >> Sent: Wednesday, March 12, 2014 9:29:28 PM >> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions >> >> On 03/12/2014 07:29 PM, Maor Lipchuk wrote: >>> On 03/12/2014 05:57 PM, Alon Bar-Lev wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Itamar Heim" >>>>> To: "Eli Mesika" , users(a)ovirt.org >>>>> Cc: "Maor Lipchuk" , "Tomasz Ko=C5=82ek" >>>>> , "infra" >>>>> Sent: Wednesday, March 12, 2014 5:52:25 PM >>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questio= ns >>>>> >>>>> On 03/12/2014 04:57 PM, Eli Mesika wrote: >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "David Caro" >>>>>>> To: "Itamar Heim" >>>>>>> Cc: "Maor Lipchuk" , users(a)ovirt.org, "Tom= asz >>>>>>> Ko=C5=82ek" >>>>>>> , "infra" >>>>>>> >>>>>>> Sent: Wednesday, March 12, 2014 11:01:21 AM >>>>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - quest= ions >>>>>>> >>>>>>> On Wed 12 Mar 2014 08:16:02 AM CET, Itamar Heim wrote: >>>>>>>> On 03/11/2014 10:08 PM, Maor Lipchuk wrote: >>>>>>>>> On 03/11/2014 05:20 PM, Itamar Heim wrote: >>>>>>>>>> On 03/11/2014 05:14 PM, Eyal Edri wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> From: "Itamar Heim" >>>>>>>>>>>> To: "Eyal Edri" , "Tomasz Ko=C5=82ek" >>>>>>>>>>>> , users(a)ovirt.org, "infra" >>>>>>>>>>>> Sent: Tuesday, March 11, 2014 5:10:54 PM >>>>>>>>>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - >>>>>>>>>>>> questions >>>>>>>>>>>> >>>>>>>>>>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote: >>>>>>>>>>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote: >>>>>>>>>>>>>>> Tomasz Ko=C5=82ek wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've got a few questions about project description. >>>>>>>>>>>>>>> Please tell me if my problem's understanding is good or not. >>>>>>>>>>>>>>> We need to add a few flags/methods to git review module. Th= is >>>>>>>>>>>>>>> flags >>>>>>>>>>>>>>> should >>>>>>>>>>>>>>> allow to add potential reviewers in gerrit. >>>>>>>>>>>>>>> So: >>>>>>>>>>>>>>> Let's assume that we've got special flags for this operatio= ns. >>>>>>>>>>>>>>> What's >>>>>>>>>>>>>>> next? >>>>>>>>>>>>>>> 1. In gerrit system we need to add special place for potent= ial >>>>>>>>>>>>>>> reviewers? >>>>>>>>>>>>>>> 2. Potential reviewers should agree that they want to revie= w? >>>>>>>>>>>>>>> 3. We can have more than one accepted reviewer? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not sure i understood exactly what you mean by 'potential >>>>>>>>>>>>>> reviewers'. do want gerrit (hook?) to automatically add >>>>>>>>>>>>>> reviewers >>>>>>>>>>>>>> to >>>>>>>>>>>>>> a patch according to the code sent? so in fact you'll have a >>>>>>>>>>>>>> place >>>>>>>>>>>>>> somewhere for mapping code & specific developers? >>>>>>>>>>>>> >>>>>>>>>>>>> I really like this idea. Gerrit currently requires new users = to >>>>>>>>>>>>> know >>>>>>>>>>>>> who >>>>>>>>>>>>> to add as reviewers, IMHO impeding new contributors. >>>>>>>>>>>>> >>>>>>>>>>>>> One relative simple solution would be to look at who recently >>>>>>>>>>>>> touched >>>>>>>>>>>>> the files that are being modified and add them as reviewers. = This >>>>>>>>>>>>> can be >>>>>>>>>>>>> done by looking at the git log for a file. Some pseudo python >>>>>>>>>>>>> code >>>>>>>>>>>>> solution: >>>>>>>>>>>>> >>>>>>>>>>>>> reviewers =3D set() >>>>>>>>>>>>> >>>>>>>>>>>>> for modified_file in commit.files: >>>>>>>>>>>>> reviewers +=3D set(commit.author for commit in >>>>>>>>>>>>> git.log(modified_file)) >>>>>>>>>>>>> >>>>>>>>>>>>> return reviewers >>>>>>>>>>>>> >>>>>>>>>>>>> This gives a system that those who touche a file, become the >>>>>>>>>>>>> maintainer >>>>>>>>>>>>> for that file. A more complex solution could improve on that = and >>>>>>>>>>>>> limit >>>>>>>>>>>>> the reviewers added per patch. One can think of limiting to o= nly >>>>>>>>>>>>> contributions in the last X months, weigh contributions so co= mmon >>>>>>>>>>>>> committers are prefered. It could also combine several method= s. >>>>>>>>>>>>> >>>>>>>>>>>>> For example to limit to the 5 authors who touched the most fi= les: >>>>>>>>>>>>> >>>>>>>>>>>>> reviewers =3D collections.Counter() # New in python 2.7 >>>>>>>>>>>>> >>>>>>>>>>>>> for modified_file in commit.files: >>>>>>>>>>>>> reviewers +=3D collections.Counter(commit.author for >>>>>>>>>>>>> commit in >>>>>>>>>>>>> git.log(modified_file)) >>>>>>>>>>>>> >>>>>>>>>>>>> return [author for author, count in reviewers.most_common(5)] >>>>>>>>>>>>> >>>>>>>>>>>>> Since Counter also accepts a dictionary, one could also weigh= the >>>>>>>>>>>>> touched lines per file. Downside there is big >>>>>>>>>>>>> whitespace/formatting >>>>>>>>>>>>> patches can skew the line count. >>>>>>>>>>>>> >>>>>>>>>>>>> In short, I think an entire thesis could be written on the >>>>>>>>>>>>> optimal >>>>>>>>>>>>> way >>>>>>>>>>>>> to determine reviewers but a simple algorithm could do to show >>>>>>>>>>>>> the >>>>>>>>>>>>> method works. >>>>>>>>>>>>> >>>>>>>>>>>>> Does this help? >>>>>> >>>>>> Maybe it will be worth to use the information we have in Bugzilla he= re: >>>>>> >>>>>> We can browse the BZ that were closed/verified in the last XXX days >>>>>> Per BZ , we know which patches are involved, who reviewed the patche= s, >>>>>> which files were changed, when files were changed and the rank of the >>>>>> change (number of lines changed) >>>>>> I believe that from this information we can compose a simple ranking >>>>>> algorithm that its output will be a list of N potential reviewers for >>>>>> the >>>>>> patch. >>>>>> Since we can aggregate the above information for all files related to >>>>>> the >>>>>> patch we want to add reviewers, we can have this set for the whole >>>>>> patch. >>>>>> This information should be processed and stored each N days and gerr= it >>>>>> will >>>>>> be able to use it. >>>>> >>>>> why are we trying to invent hueristics, instead of declaring clear >>>>> ownership? >>>> >>>> Reminder: my source metadata plan that requires cooperation. >>>> >>>> Each source and component should have an explicit ownership up into bug >>>> database. >>>> >>>> I won't repeat it now, it is available at archives. >>>> >>> I think we are discussing two different issues here: >>> The first one considers the GSOC project, of adding reviewers >>> automatically to a patch, this can be done in many different heuristics >>> depending what the submitter prefers (use blame, maintainers who acked >>> the patches, bugs, list of owners to a file and so on). >> >> that's the point. we should be using heuristics, rather ownership. obvioulsy i meant here: we should *not* be using heuristics, rather = ownership. > > I want heuristics to solve bugs as well. > Maybe for each issue I will use heuristic and wait for X days for someone= else to fix? > I would like to see how you build a building using heuristic reviews. > >> this could still be done via a GSOC project for implementing the gerrit >> logic to do so. >> >>> >>> The second issue is adding and maintain a list of owners by >>> files/folders in oVirt. >>> this is a specific use case to be used by the "add potential reviewers" >>> project. >>> >>>>> >>>>>> >>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Users mailing list >>>>>>>>>>>>> Users(a)ovirt.org >>>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I think if we do this, we want to make sure we cover per file = who >>>>>>>>>>>> is >>>>>>>>>>>> required to +2 it before we consider it acked. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> won't it require maintaining static lists of people per >>>>>>>>>>> file/path/project? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> yes, but considering our project layout, i don't see an alternat= ive. >>>>>>>>>> (some of the layout could be improved to be path based, rather t= han >>>>>>>>>> file >>>>>>>>>> based) >>>>>>>>> I think it could be done automatically by analysing the file and = see >>>>>>>>> who >>>>>>>>> mostly changed it recently, since the "owner" of the file might be >>>>>>>>> dynamic, who ever changed most of it few days ago might be more >>>>>>>>> familiar >>>>>>>>> with it today >>>>>>>>> >>>>>>>>> IMO the algorithm of adding the reviewers should be flexible. >>>>>>>>> For example, using a folder which will contain files, where each = file >>>>>>>>> implement an algorithm to add the reviewers. >>>>>>>>> >>>>>>>>> for instance we can have two files: >>>>>>>>> 1. Add a reviewers by blame - the contributor which changed recen= tly >>>>>>>>> the >>>>>>>>> code lines >>>>>>>>> 2. Add a reviewers by file - the contributor who changed most of = the >>>>>>>>> file recently. >>>>>>>>> >>>>>>>>> Each file will implement the functional operation and will output= the >>>>>>>>> reviewers emails. >>>>>>>>> >>>>>>>>> The user can then add a new algorithm or change it to be more >>>>>>>>> specific >>>>>>>>> to its project. >>>>>>>>> for example the user can add also the maintainers which acked the >>>>>>>>> patch >>>>>>>>> that was blamed. >>>>>>>>>> _______________________________________________ >>>>>>>>>> Users mailing list >>>>>>>>>> Users(a)ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>>>>> >>>>>>>> >>>>>>>> this shouldn't be automatic. we need to clearly define ownership. = we >>>>>>>> can't >>>>>>>> do >>>>>>>> this per repo for the engine/vdsm. we can do this per repo for the >>>>>>>> other >>>>>>>> repo's probably (though solving the folder/file approach would cov= er >>>>>>>> the >>>>>>>> simpler repos as a private case). >>>>>>>> >>>>>>>> yes, it will require some work, maybe some moving around of files = to >>>>>>>> make >>>>>>>> this >>>>>>>> easier by folders (topics) which should be relevant anyway. >>>>>>> >>>>>>> I think it would easier to maintain if we just have one file at the >>>>>>> root, instead of having the ownership information distributed >>>>>>> throughout the files/directories. That way you'll know where to loo= k at >>>>>>> to check/modify the ownership as opposed to having to walk all the >>>>>>> files and upper directories. >>>>>>> >>>>>>> Also, adding all that ownership logic to gerrit might not be easy, = as >>>>>>> it's not meant to go checking the source of the repositories looking >>>>>>> for configuration. We might want to take a look (again) to zuul, the >>>>>>> tool that openstack uses as gateway to trigger jenkins jobs and mer= ge >>>>>>> patches. >>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Infra mailing list >>>>>>>> Infra(a)ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> David Caro >>>>>>> >>>>>>> Red Hat S.L. >>>>>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D >>>>>>> >>>>>>> Email: dcaro(a)redhat.com >>>>>>> Web: www.redhat.com >>>>>>> RHT Global #: 82-62605 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Infra mailing list >>>>>>> Infra(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> Infra mailing list >>>>> Infra(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>> >>> >> >> --===============6998700668829007194==--