Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Issues with contributors generating script #2028
This is going off from R#2024.
There are these issues present in the contributors generating script that caused or have potential to cause us to miss contributors:
Relying on the time when release manager runs the contributor script, potentially creating a gap of unrecorded contributions between the time the script is run and the time the next run considers as "last release".
The script currently uses the timestamp on rakudo's tag to determine the time of last release. However, there's a gap between the time when the release announcement is generated and when the tag is created. Anyone who makes a contribution during that time period is lost.
This can potentially be fixed by recording (in some file in rakudo's repo) the last commits of each repo that were recorded for a release, and starting next release from those commits
Relying on release manager's setup of directories/repos
We've missed a lot of contributors in 2016 because of the contributors script silently ignoring missing repo checkouts. However, even after a previous fix in this area, we're still relying on the release manager to have up-to-date checkouts of repos (I think they have to be in the right branch too).
This can potentially be fixed by using GitHub API to query info for new commits, like Geth bot does
What happens with commits made at the time of past release in a branch that are merged at the time of the next release?
Do they get lost? During my run of the contributors script with
Missing contributors from entire repositories due to unnoticed bug in the code
We've been missing all contributors from MoarVM since 2016.09 due to R#2024 but that went unnoticed.
Unsure if a solution to detect this is needed or possible. We could split the contributors list in the announcement into 5 categories, one for each repo (the downside is that waters down the total amount of commits the user made, which is currently used to sort the list).
Repos list is kinda arbitrary
I think it should simply work based on the tagged commit. Just looking at the log of tag..HEAD should be enough, as far as I know. Why it wasn't done this way in the first place is unknown to me.
Yes, this is somewhat annoying, but at the same time it allows me to use a branch of my choice (e.g. a release branch like I did for the very last few releases). It is still annoying because it has to be checked out in all repos properly…
added a commit
Jul 5, 2018
Published my research that led to this Issue as well as a list of missing contributors in https://rakudo.party/post/The-Missing-Contributors-of-Perl6
Once thing I noticed is the contrib script genned a new list for past releases that did not have one or more people that were on the announcement (just some historical artefact of people adding/changing their names in CREDITS?)
Also, I notice brrt is the frequent-misser on the list, missing even before the MoarVM-repo-dropping bug was introduced. One thing I recall is they were working on a JIT branch for year+. So I think their "missing" from the announcements is just those old commits that are now in master showing up as if they were in those releases?
Anyway, something about the script is really wonky.
Ah… right. Maybe I should start tagging roast with rakudo-specific tags (e.g.
As for the doc repo, I think it has to rely on log xxx..HEAD mechanism also, even if there are no tags. I think when merging old pull requests the commit date can be much older (have older committer/author dates), so
Pretty sure they won't be lost if
Alright, so I worked a few hours on this today… it's a bit more difficult than it sounds. I am on the right track though, so sooner or later it will be done.
I understand that it is very important to generate the list properly, but depending on issues with other release-related things, this may no be ready before this release. I'm removing the blocker label because technically it is not blocking us from cutting this release, but I'll try to get it done asap.