7:40 p.m.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--8g2T7IQmS1E8OmSlnIBno6eqBl8hkAFtD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue 11 Mar 2014 04:14:26 PM CET, Eyal Edri wrote:
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Eyal Edri" <eedri(a)redhat.com>, "Tomasz Ko=C5=82ek"
<tomasz-kolek@=
o2.pl>, users(a)ovirt.org, "infra"
<infra(a)ovirt.org>
> Sent: Tuesday, March 11, 2014 5:10:54 PM
> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - question=
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=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 revi=
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=
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 =
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 limi=
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 =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 wa=
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=
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=20
proposed was to add metadata on each file/directory about the=20
maintainers for that file/directory. For what I've seen in other=20
projects (mainly openstack), they do that per repository, and not per=20
file, that simplifies the maintainers selection greatly (having it on=20
gerrit config so you don't have to check the code to decide who has=20
merge rights).
But that might be another subject.
About dynamically adding reviewers, it should be fairly easy to do=20
using a small gerrit hook to run on patch-submitted. But gerrit will=20
fail if the user is not already created in gerrit so not really=20
allowing non-registered users to get in. But I'm not sure if it's=20
'polite' to add someone as a reviewer if he did not previously agreed=20
to it, specially when emails will be sent to him.
And as Ewoud says, selecting which commiters are considered possible=20
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="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJTHzxiAAoJEEBxx+HSYmnD2ZEH/1i8of7ywJaIwKKyxzgyYp2H
AUlZRkqCbdZTkVrMSIFsXikuRnEVeJY0eXVd5G4mco2Qf7962+dpW2xjLctJL8T0
YaLXiQUR+TvpnBp5OvB0870hhKo9ql010KjijjediMceswENSV6fwciQn+zvdUfe
MkCD6/I5aB4vwLGm7CUIB64lLeaSbYGoAUJYc3XkH+czKmSJce1D4JD3xCDufLLE
NDu0jdcHizss0czsWzwG8k8twDE/MVgaLmd0xiU3Mvjg3pkQ6h7mUQMe7spRWpJM
FOSI+MBek1q+mxtcbsuGpPvyT5WqyoKA6XzYWrWdclvCfzQiYhRJ1eQTjUIgKcE=
=7A1Y
-----END PGP SIGNATURE-----
--8g2T7IQmS1E8OmSlnIBno6eqBl8hkAFtD--