[
https://issues.apache.org/jira/browse/COMDEV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved COMDEV-164.
-------------------------
Resolution: Fixed
URL: http://svn.apache.org/viewvc?rev=1706165&view=rev
Log:
COMDEV-164 parsepmcs.py does not handle new groups correctly
COMDEV-167 parsepmcs.py regex for committer groups also matches -pmc groups
Modified:
comdev/reporter.apache.org/trunk/data/parsepmcs.py
> parsepmcs.py does not handle new groups correctly
> -------------------------------------------------
>
> Key: COMDEV-164
> URL: https://issues.apache.org/jira/browse/COMDEV-164
> Project: Community Development
> Issue Type: Bug
> Components: Reporter Tool
> Reporter: Sebb
>
> The parsepmcs.py script currently parses
> http://people.apache.org/committer-index.html and generates lists of the auth
> groups that committers belong to, as well as the date when the person was
> first added to the new group. When a new group is seen, all the joining dates
> are 0, so the JSON files can be used to show subsequent changes to the auth
> groups without needing to know when the group itself was first seen.
> However the process is broken, because it keeps track of new groups using the
> same array for both committee (e.g. abdera-pmc) and committer (e.g. abdera)
> groups. This would be fine except the "-pmc" suffix is stripped from the
> group name before it is stored in the array. Thus once the committer group is
> seen, the committee group won't be regarded as new if it is added in a future
> run. And vice versa. The process only works if the two groups are added in
> the same run, and even then there is an issue because the check for the new
> committer group is only done if it has not just been added. (the check for
> new committee group is OK).
> It looks like the only effect of this is to record some ids as having a
> joining date when in fact they should not because they were part of the
> initial group.
> This can be fixed by manually editting the json files, though determining
> which entries need to be fixed may not be trivial.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
