API for bugs.python.org or some statistic about lib/module merge rate?
Hi all, After reading some topic at python-committers mailing list, some of the topics are around not enough reviewers to review patches, cause the develop process slowing down or the patch can't merge into the codebase. I would like to make some analysis about module / library patch merge rate (maybe fine-grained to per file?), and make a statistic list that can point out which module / library need more people to contribute to it. Are there any API for bugs.python.org can be used, or there is a existing thing just doing what I want to do. (Or maybe Python tracker, who sent the summary can add this kind of function.) Thanks, Louie.
I don't think there's any API. Your best bet will probably be to analyze the GitHub data. On Tue, 18 Apr 2017 at 09:09 Louie Lu <me@louie.lu> wrote:
Hi all,
After reading some topic at python-committers mailing list, some of the topics are around not enough reviewers to review patches, cause the develop process slowing down or the patch can't merge into the codebase.
I would like to make some analysis about module / library patch merge rate (maybe fine-grained to per file?), and make a statistic list that can point out which module / library need more people to contribute to it.
Are there any API for bugs.python.org can be used, or there is a existing thing just doing what I want to do. (Or maybe Python tracker, who sent the summary can add this kind of function.)
Thanks, Louie. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
I used the download CSV function, and make some change about it. The demo of the site is here: https://bpo-mergerate.louie.lu/ To used, just need to enter the prefix of dictionary to search bar, for now, its resolution is to the second folder or files, e.g., Lib/unittest, Python/ceval.c 2017-04-20 5:04 GMT+08:00 Brett Cannon <brett@python.org>:
I don't think there's any API. Your best bet will probably be to analyze the GitHub data.
On Tue, 18 Apr 2017 at 09:09 Louie Lu <me@louie.lu> wrote:
Hi all,
After reading some topic at python-committers mailing list, some of the topics are around not enough reviewers to review patches, cause the develop process slowing down or the patch can't merge into the codebase.
I would like to make some analysis about module / library patch merge rate (maybe fine-grained to per file?), and make a statistic list that can point out which module / library need more people to contribute to it.
Are there any API for bugs.python.org can be used, or there is a existing thing just doing what I want to do. (Or maybe Python tracker, who sent the summary can add this kind of function.)
Thanks, Louie. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ brett%40python.org
Roundup has an xmlrpc API: - https://sourceforge.net/p/roundup/code/ci/default/tree/roundup/xmlrpc.py - https://sourceforge.net/p/roundup/code/ci/default/tree/test/test_xmlrpc.py http://roundup.sourceforge.net https://sourceforge.net/p/roundup/code/ Tangentially, here's a PR to add gh pr http webhook support to Roundup: https://github.com/AnishShah/roundup/commit/84cdf84946835c883a1384c4ece64935... April 19, 2017, Louie Lu <me@louie.lu> wrote:
I used the download CSV function, and make some change about it.
The demo of the site is here:
https://bpo-mergerate.louie.lu/
To used, just need to enter the prefix of dictionary to search bar, for now, its resolution is to the second folder or files, e.g., Lib/unittest, Python/ceval.c
This searches files changed in issue patch attachments or more like e.g. `git log Lib/unittest` `git blame Lib/unittest`?
2017-04-20 5:04 GMT+08:00 Brett Cannon <brett@python.org <javascript:_e(%7B%7D,'cvml','brett@python.org');>>:
I don't think there's any API. Your best bet will probably be to analyze the GitHub data.
On Tue, 18 Apr 2017 at 09:09 Louie Lu <me@louie.lu <javascript:_e(%7B%7D,'cvml','me@louie.lu');>> wrote:
Hi all,
After reading some topic at python-committers mailing list, some of the topics are around not enough reviewers to review patches, cause the develop process slowing down or the patch can't merge into the codebase.
I would like to make some analysis about module / library patch merge rate (maybe fine-grained to per file?), and make a statistic list that can point out which module / library need more people to contribute to it.
Are there any API for bugs.python.org can be used, or there is a existing thing just doing what I want to do. (Or maybe Python tracker, who sent the summary can add this kind of function.)
Thanks, Louie. _______________________________________________ Python-Dev mailing list Python-Dev@python.org <javascript:_e(%7B%7D,'cvml','Python-Dev@python.org');> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett% 40python.org
On 21 April 2017 at 06:04, Wes Turner <wes.turner@gmail.com> wrote:
Roundup has an xmlrpc API:
- https://sourceforge.net/p/roundup/code/ci/default/tree/roundup/xmlrpc.py - https://sourceforge.net/p/roundup/code/ci/default/tree/test/test_xmlrpc.py
There's also a pending patch to add a HTTPS+JSON REST API to our Roundup instance: http://psf.upfronthosting.co.za/roundup/meta/issue581 Definite +1 for the general idea of collecting and publishing these kinds of statistics, though - I can see them being quite useful to a variety of audiences. Cheers, Nick. P.S. The upstream Roundup project is also interested in offering that capability by default: http://issues.roundup-tracker.org/issue2550734 -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi all, thanks for all your reply, since roundup didn't contain JSON REST API, and I'm not sure did roundup robot have deal with "patched but still open" situation, thus I do some change to bpo-mergerate and have some result. GitHub repo: https://github.com/lulouie/bpo-mergerate Demo site: https://bpo-mergerate.louie.lu Now bpo-mergerate using SQLite database and no more CSV file, and an update.py script was added, on my host, it will automatically update the bpo patch status hourly. For the site, it is now using ajax and can deal with fuzzy search. The merge rate calculate is now find-grained to per-file, and will automatically count the prefix merge rate, for example: Searching: Lib/test Result: path merged open total rate /Lib/test 3013 1359 4372 68.916 Lib/test/test_ssl.py 60 15 75 80.000 Lib/test/test_inspect.py 56 12 68 82.353 I think the site function is complete now, welcome for any suggestion. (maybe like speed.python.org make a timeline for the merge rate?) Best Regards, Louie. 2017-04-24 12:08 GMT+08:00 Nick Coghlan <ncoghlan@gmail.com>:
On 21 April 2017 at 06:04, Wes Turner <wes.turner@gmail.com> wrote:
Roundup has an xmlrpc API:
- https://sourceforge.net/p/roundup/code/ci/default/tree/ roundup/xmlrpc.py - https://sourceforge.net/p/roundup/code/ci/default/tree/ test/test_xmlrpc.py
There's also a pending patch to add a HTTPS+JSON REST API to our Roundup instance: http://psf.upfronthosting.co.za/roundup/meta/issue581
Definite +1 for the general idea of collecting and publishing these kinds of statistics, though - I can see them being quite useful to a variety of audiences.
Cheers, Nick.
P.S. The upstream Roundup project is also interested in offering that capability by default: http://issues.roundup-tracker.org/issue2550734
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Monday, April 24, 2017, Louie Lu <me@louie.lu> wrote:
Hi all,
thanks for all your reply, since roundup didn't contain JSON REST API, and I'm not sure did roundup robot have deal with "patched but still open" situation, thus I do some change to bpo-mergerate and have some result.
GitHub repo: https://github.com/lulouie/bpo-mergerate Demo site: https://bpo-mergerate.louie.lu
Now bpo-mergerate using SQLite database and no more CSV file, and an update.py script was added, on my host, it will automatically update the bpo patch status hourly. For the site, it is now using ajax and can deal with fuzzy search.
The merge rate calculate is now find-grained to per-file, and will automatically count the prefix merge rate, for example:
Searching: Lib/test Result: path merged open total rate /Lib/test 3013 1359 4372 68.916 Lib/test/test_ssl.py 60 15 75 80.000 Lib/test/test_inspect.py 56 12 68 82.353
I think the site function is complete now, welcome for any suggestion. (maybe like speed.python.org make a timeline for the merge rate?)
Nice work. Additional per-file factors worth visualizing: - change in test coverage - change in relevant docs.rst - build job ids (which patch on which arch) - benchmark timings - git log --stat Gource is a pretty cool way to visualize file changes by author over time: http://gource.io "Evolution of CPython (gource visualization)" https://youtu.be/tZVG57xFwMk Is there something like `hg churn` for git? I haven't had need; but just found: - https://www.mercurial-iscm.org/wiki/ChurnExtension - https://gist.github.com/aras-p/8289222 (cheat sheet) Does ChurnExtension work with hg-git? - https://github.com/arzzen/git-quick-stats https://github.com/arzzen/git-quick-stats/blob/master/git-quick-stats (bash script) - https://github.com/IonicaBizau/git-stats Json? JSON-LD with the file path as the resource @id really would be great (and mergeable from various build artifacts): - https://www.google.com/search?q=elasticsearch+git+log - westurner/pyrpo canould write streaming JSON from `git log` but not yet `git log --stat` - {SQLAlchemy(SQLite), } > JSON-LD reports with @id URIs for {source, docs} file paths
Best Regards, Louie.
2017-04-24 12:08 GMT+08:00 Nick Coghlan <ncoghlan@gmail.com <javascript:_e(%7B%7D,'cvml','ncoghlan@gmail.com');>>:
On 21 April 2017 at 06:04, Wes Turner <wes.turner@gmail.com <javascript:_e(%7B%7D,'cvml','wes.turner@gmail.com');>> wrote:
Roundup has an xmlrpc API:
- https://sourceforge.net/p/roundup/code/ci/default/tree/round up/xmlrpc.py - https://sourceforge.net/p/roundup/code/ci/default/tree/test/ test_xmlrpc.py
There's also a pending patch to add a HTTPS+JSON REST API to our Roundup instance: http://psf.upfronthosting.co.za/roundup/meta/issue581
Definite +1 for the general idea of collecting and publishing these kinds of statistics, though - I can see them being quite useful to a variety of audiences.
Cheers, Nick.
P.S. The upstream Roundup project is also interested in offering that capability by default: http://issues.roundup-tracker.org/issue2550734
-- Nick Coghlan | ncoghlan@gmail.com <javascript:_e(%7B%7D,'cvml','ncoghlan@gmail.com');> | Brisbane, Australia
Hi all, Current merge rate is count in a mixed way (patch + PR). After reading Bertt's post "The history behind the decision to move Python to GitHub", I would like to separate the count of merge rate to hg and GitHub. It may check that did migrate to GitHub get the better process of CPython development. Best Regards, Louie. 2017-04-24 23:55 GMT+08:00 Louie Lu <me@louie.lu>:
Hi all,
thanks for all your reply, since roundup didn't contain JSON REST API, and I'm not sure did roundup robot have deal with "patched but still open" situation, thus I do some change to bpo-mergerate and have some result.
GitHub repo: https://github.com/lulouie/bpo-mergerate Demo site: https://bpo-mergerate.louie.lu
Now bpo-mergerate using SQLite database and no more CSV file, and an update.py script was added, on my host, it will automatically update the bpo patch status hourly. For the site, it is now using ajax and can deal with fuzzy search.
The merge rate calculate is now find-grained to per-file, and will automatically count the prefix merge rate, for example:
Searching: Lib/test Result: path merged open total rate /Lib/test 3013 1359 4372 68.916 Lib/test/test_ssl.py 60 15 75 80.000 Lib/test/test_inspect.py 56 12 68 82.353
I think the site function is complete now, welcome for any suggestion. (maybe like speed.python.org make a timeline for the merge rate?)
Best Regards, Louie.
2017-04-24 12:08 GMT+08:00 Nick Coghlan <ncoghlan@gmail.com>:
On 21 April 2017 at 06:04, Wes Turner <wes.turner@gmail.com> wrote:
Roundup has an xmlrpc API:
- https://sourceforge.net/p/roundup/code/ci/default/tree/round up/xmlrpc.py - https://sourceforge.net/p/roundup/code/ci/default/tree/test/ test_xmlrpc.py
There's also a pending patch to add a HTTPS+JSON REST API to our Roundup instance: http://psf.upfronthosting.co.za/roundup/meta/issue581
Definite +1 for the general idea of collecting and publishing these kinds of statistics, though - I can see them being quite useful to a variety of audiences.
Cheers, Nick.
P.S. The upstream Roundup project is also interested in offering that capability by default: http://issues.roundup-tracker.org/issue2550734
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi all, Fix some pr counting issue, and now the bpo-mergerate can choose hg (the old process), git, or all for mergerate counting. Also, relative bpo issue can be expand by clicking row for more detail. demo site: https://bpo-mergerate.louie.lu Best Regards, Louie. 2017-04-25 16:18 GMT+08:00 Louie Lu <me@louie.lu>:
Hi all,
Current merge rate is count in a mixed way (patch + PR).
After reading Bertt's post "The history behind the decision to move Python to GitHub", I would like to separate the count of merge rate to hg and GitHub.
It may check that did migrate to GitHub get the better process of CPython development.
Best Regards, Louie.
2017-04-24 23:55 GMT+08:00 Louie Lu <me@louie.lu>:
Hi all,
thanks for all your reply, since roundup didn't contain JSON REST API, and I'm not sure did roundup robot have deal with "patched but still open" situation, thus I do some change to bpo-mergerate and have some result.
GitHub repo: https://github.com/lulouie/bpo-mergerate Demo site: https://bpo-mergerate.louie.lu
Now bpo-mergerate using SQLite database and no more CSV file, and an update.py script was added, on my host, it will automatically update the bpo patch status hourly. For the site, it is now using ajax and can deal with fuzzy search.
The merge rate calculate is now find-grained to per-file, and will automatically count the prefix merge rate, for example:
Searching: Lib/test Result: path merged open total rate /Lib/test 3013 1359 4372 68.916 Lib/test/test_ssl.py 60 15 75 80.000 Lib/test/test_inspect.py 56 12 68 82.353
I think the site function is complete now, welcome for any suggestion. (maybe like speed.python.org make a timeline for the merge rate?)
Best Regards, Louie.
2017-04-24 12:08 GMT+08:00 Nick Coghlan <ncoghlan@gmail.com>:
On 21 April 2017 at 06:04, Wes Turner <wes.turner@gmail.com> wrote:
Roundup has an xmlrpc API:
- https://sourceforge.net/p/roundup/code/ci/default/tree/round up/xmlrpc.py - https://sourceforge.net/p/roundup/code/ci/default/tree/test/ test_xmlrpc.py
There's also a pending patch to add a HTTPS+JSON REST API to our Roundup instance: http://psf.upfronthosting.co.za/roundup/meta/issue581
Definite +1 for the general idea of collecting and publishing these kinds of statistics, though - I can see them being quite useful to a variety of audiences.
Cheers, Nick.
P.S. The upstream Roundup project is also interested in offering that capability by default: http://issues.roundup-tracker.org/issue2550734
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Thanks for this, Louie! Definitely interesting to look at what modules have the most open patches against them (spoiler alert: it's apparently argparse with 51). On Tue, 25 Apr 2017 at 22:18 Louie Lu <me@louie.lu> wrote:
Hi all,
Fix some pr counting issue, and now the bpo-mergerate can choose hg (the old process), git, or all for mergerate counting. Also, relative bpo issue can be expand by clicking row for more detail.
demo site: https://bpo-mergerate.louie.lu
Best Regards, Louie.
2017-04-25 16:18 GMT+08:00 Louie Lu <me@louie.lu>:
Hi all,
Current merge rate is count in a mixed way (patch + PR).
After reading Bertt's post "The history behind the decision to move Python to GitHub", I would like to separate the count of merge rate to hg and GitHub.
It may check that did migrate to GitHub get the better process of CPython development.
Best Regards, Louie.
2017-04-24 23:55 GMT+08:00 Louie Lu <me@louie.lu>:
Hi all,
thanks for all your reply, since roundup didn't contain JSON REST API, and I'm not sure did roundup robot have deal with "patched but still open" situation, thus I do some change to bpo-mergerate and have some result.
GitHub repo: https://github.com/lulouie/bpo-mergerate Demo site: https://bpo-mergerate.louie.lu
Now bpo-mergerate using SQLite database and no more CSV file, and an update.py script was added, on my host, it will automatically update the bpo patch status hourly. For the site, it is now using ajax and can deal with fuzzy search.
The merge rate calculate is now find-grained to per-file, and will automatically count the prefix merge rate, for example:
Searching: Lib/test Result: path merged open total rate /Lib/test 3013 1359 4372 68.916 Lib/test/test_ssl.py 60 15 75 80.000 Lib/test/test_inspect.py 56 12 68 82.353
I think the site function is complete now, welcome for any suggestion. (maybe like speed.python.org make a timeline for the merge rate?)
Best Regards, Louie.
2017-04-24 12:08 GMT+08:00 Nick Coghlan <ncoghlan@gmail.com>:
On 21 April 2017 at 06:04, Wes Turner <wes.turner@gmail.com> wrote:
Roundup has an xmlrpc API:
- https://sourceforge.net/p/roundup/code/ci/default/tree/roundup/xmlrpc.py - https://sourceforge.net/p/roundup/code/ci/default/tree/test/test_xmlrpc.py
There's also a pending patch to add a HTTPS+JSON REST API to our Roundup instance: http://psf.upfronthosting.co.za/roundup/meta/issue581
Definite +1 for the general idea of collecting and publishing these kinds of statistics, though - I can see them being quite useful to a variety of audiences.
Cheers, Nick.
P.S. The upstream Roundup project is also interested in offering that capability by default: http://issues.roundup-tracker.org/issue2550734
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
On 4/26/2017 1:17 AM, Louie Lu wrote:
Fix some pr counting issue, and now the bpo-mergerate can choose hg (the old process), git, or all for mergerate counting. Also, relative bpo issue can be expand by clicking row for more detail.
Details do not seem to be correct. I searched for 'Lib/idlelib'. For pyshell.py, it says 3 merged, 1 open. I clicked and got bpo issues: 29162 29581 29919 30067 The 'open' one is https://bugs.python.org/issue29581, patch at https://github.com/python/cpython/pull/527/commits/de5d514e649729a1f9e6f3e13... seems to be an error. Lib/idlelib/idle_test/test_calltips.py has 1 and 1 bpo issues: 20185 22392 24665 None of these are idlelib issues.
demo site: https://bpo-mergerate.louie.lu
-- Terry Jan Reedy
Thanks for the reply, 2017-04-27 14:14 GMT+08:00 Terry Reedy <tjreedy@udel.edu>:
On 4/26/2017 1:17 AM, Louie Lu wrote:
Fix some pr counting issue, and now the bpo-mergerate can choose hg (the old process), git, or all for mergerate counting. Also, relative bpo issue can be expand by clicking row for more detail.
Details do not seem to be correct. I searched for 'Lib/idlelib'. For pyshell.py, it says 3 merged, 1 open. I clicked and got bpo issues: 29162 29581 29919 30067 The 'open' one is https://bugs.python.org/issue29581, patch at https://github.com/python/cpython/pull/527/commits/de5d514e649729a1f9e6f3e13... seems to be an error.
You are right, somehow database was wrong, and cannot deal with path change (if there is a change after fetching). Rebuild and fix this problem.
Lib/idlelib/idle_test/test_calltips.py has 1 and 1 bpo issues: 20185 22392 24665 None of these are idlelib issues.
Not that directly, but these bpo issue PR has changed the file. See: bpo-20185: PR 542 bpo-24665: PR 89, and a issue fixed but close PR 898. The detail now will show the relative PR (which bpo and which PR that is merged, fixed, or open) inside. e.g. Lib/idlelib/idle_test/test_calltips.py bpo issues: 20185 22392 24665 PR: bpo-20185: PR 542 bpo-24665: PR 89 Best Regards, Louie.
On 4/27/2017 7:57 AM, Louie Lu wrote:
Lib/idlelib/idle_test/test_calltips.py has 1 and 1 bpo issues: 20185 22392 24665 None of these are idlelib issues.
Not that directly, but these bpo issue PR has changed the file. See: bpo-20185: PR 542 bpo-24665: PR 89, and a issue fixed but close PR 898.
#20185: The PR number is *very* helpful. This issue has multiple patches and 5 PRs merged to default. #22392: PR 89 has about 10 commits. The original, easy-to-find patch, https://github.com/python/cpython/pull/89/commits/6ea78e33b599605b0c1c35fbbc... did not touch test_calltips. It is touched by the latest, not so easy-to-find commit https://github.com/python/cpython/pull/89/commits/54de7aa6c6fffe9b2248153051... I don't know how to get the complete merged diff that would be applied if the green button were pressed. #22392 has PR 899 (merged) and PR 898 (closed). The latter was a blunder that incorporated about 100 already applied patches, mostly from 2016. Take a look. https://github.com/python/cpython/pull/898 Part of doing good statistics is removing bogus data from datasets. Even though you cannot remove 898 from github, you should ignore it in your analysis. All the hits it generates are false positives. This is probably the source of many other false hits for idlelib.
The detail now will show the relative PR (which bpo and which PR that is merged, fixed, or open) inside.
e.g. Lib/idlelib/idle_test/test_calltips.py bpo issues: 20185 22392 24665 PR: bpo-20185: PR 542 bpo-24665: PR 89
Note that 898 is so bogus that it cannot be handled properly. For me, the immediate use case is to find patches to idlelib by others that I am not aware of, like the two real ones to test_calltips. I would like an entry box for the start date to put in date last checked. What would be really super would to be able to exclude issues (and associated patches) assigned to me. When you get this polished, I hope you open an issue and PR to add it to one of the cpython and mention it in the devguide. -- Terry Jan Reedy
2017-04-28 4:06 GMT+08:00 Terry Reedy <tjreedy@udel.edu>:
On 4/27/2017 7:57 AM, Louie Lu wrote:
Lib/idlelib/idle_test/test_calltips.py has 1 and 1 bpo issues: 20185 22392 24665 None of these are idlelib issues.
Not that directly, but these bpo issue PR has changed the file. See: bpo-20185: PR 542 bpo-24665: PR 89, and a issue fixed but close PR 898.
#20185: The PR number is *very* helpful. This issue has multiple patches and 5 PRs merged to default.
#22392: PR 89 has about 10 commits. The original, easy-to-find patch, https://github.com/python/cpython/pull/89/commits/6ea78e33b599605b0c1c35fbbc... did not touch test_calltips.
It is touched by the latest, not so easy-to-find commit https://github.com/python/cpython/pull/89/commits/54de7aa6c6fffe9b2248153051...
I don't know how to get the complete merged diff that would be applied if the green button were pressed.
#22392 has PR 899 (merged) and PR 898 (closed). The latter was a blunder that incorporated about 100 already applied patches, mostly from 2016. Take a look. https://github.com/python/cpython/pull/898
Part of doing good statistics is removing bogus data from datasets. Even though you cannot remove 898 from github, you should ignore it in your analysis. All the hits it generates are false positives. This is probably the source of many other false hits for idlelib.
Now add the blacklist for PR, this is still manual to add into the config I have three cases: PR 898, PR 703, and PR 552. The "automatic" identified should be add in future (probably)
The detail now will show the relative PR (which bpo and which PR that is merged, fixed, or open) inside.
e.g. Lib/idlelib/idle_test/test_calltips.py bpo issues: 20185 22392 24665 PR: bpo-20185: PR 542 bpo-24665: PR 89
Note that 898 is so bogus that it cannot be handled properly.
For me, the immediate use case is to find patches to idlelib by others that I am not aware of, like the two real ones to test_calltips. I would like an entry box for the start date to put in date last checked. What would be
The latest bpo-issue check date will now be shown when the cursor hovers on the issue. (That mean, mobile can't see the date now. I think (on mobile) this isn't that needed)
really super would to be able to exclude issues (and associated patches) assigned to me.
This may be update in the future. (Assignee from bpo or GitHub?)
When you get this polished, I hope you open an issue and PR to add it to one of the cpython and mention it in the devguide.
Yes, I will. A small question what does it mean "add it to one of the cpython"?
-- Terry Jan Reedy
Best Regards, Louie.
I believe this is a great initiative :). On Apr 18, 2017 12:09, "Louie Lu" <me@louie.lu> wrote:
Hi all,
After reading some topic at python-committers mailing list, some of the topics are around not enough reviewers to review patches, cause the develop process slowing down or the patch can't merge into the codebase.
I would like to make some analysis about module / library patch merge rate (maybe fine-grained to per file?), and make a statistic list that can point out which module / library need more people to contribute to it.
Are there any API for bugs.python.org can be used, or there is a existing thing just doing what I want to do. (Or maybe Python tracker, who sent the summary can add this kind of function.)
Thanks, Louie.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric. lafontaine1%40gmail.com
participants (6)
-
Brett Cannon -
Eric Lafontaine -
Louie Lu -
Nick Coghlan -
Terry Reedy -
Wes Turner