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@redhat.com> To: "Eyal Edri" <eedri@redhat.com>, "Tomasz Ko=C5=82ek" <tomasz-kolek@=
o2.pl>, users@ovirt.org, "infra" <infra@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@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@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@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--