New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with contributors generating script #2028

Open
zoffixznet opened this Issue Jul 5, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@zoffixznet
Contributor

zoffixznet commented Jul 5, 2018

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 for release ... feature for past release lookup, I'm consistently getting 3-4 names I can't really explain why they're missing. Are these people from the "gaps" of the release or are these branches being merged with commits from them landing into the already-shipped releases and thus never seen by the script?

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

For example rakudo/star isn't tracked; none of our websites repos are tracked. I'm just wondering if there's anyone else out there being upset that their work is never credited (like it was with the person who got missed twice on current list)?

@AlexDaniel

This comment has been minimized.

Member

AlexDaniel commented Jul 5, 2018

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

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.

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).

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…

@zoffixznet

This comment has been minimized.

Contributor

zoffixznet commented Jul 5, 2018

Why it wasn't done this way in the first place is unknown to me

Docs and roast ain't got no tags tho

zoffixznet added a commit that referenced this issue Jul 5, 2018

Add missing persons from contributing lists in past announcements
Fixes #2024 R#2024 with the
reasons for missings listed on R#2028
#2028

I've added missing persons with "as well as" clause. When I ran the
contrib script to gen the list for past releases, I had someone
who was on the announcement but not in the script output for pretty
much every release. I suspect these people might've got added/modified
their names in the CREDITS file, but since I'm unable to merge the
original list (sorted by commit count) with the new list, I've added
the missing people list with "as well as" and the missing list is
sorted alphabetically.
@zoffixznet

This comment has been minimized.

Contributor

zoffixznet commented 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.

@AlexDaniel

This comment has been minimized.

Member

AlexDaniel commented Jul 5, 2018

Docs and roast ain't got no tags tho

Ah… right. Maybe I should start tagging roast with rakudo-specific tags (e.g. rakudo-2018.05). For example, if today you decide to spectest 2018.05 against roast master, then only I know which commit was used when I was doing the release. Moreover, for latest releases when I was cutting from a release branch, I had to actually write out a commit hash for roast (because by the time the release was cut there were new tests that covered post-release bug fixes and whatever).

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 --since can filter that out. So there's a chance that more people are missing.

What happens with commits made at the time of past release in a branch that is merged at the time of the next release? Do they get lost?

Pretty sure they won't be lost if git log xxx..HEAD is used.

@AlexDaniel

This comment has been minimized.

Member

AlexDaniel commented Jul 25, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment