jakartaee / jakartaee/collateral

[Contributor Card Tools for Releases] ~tampering with commit history w/ Squash

Open
#73 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
No language data
Stars
4
Forks
9
PR merge metrics
No merged PRs in 30d

Description

During the Sept 8th TCK call, we discussed squash vs not squash and its impact on the Jakarta Releases Contributors' cards history that populates the release page cards.

Thanks to @scottmarlow, we know that TCK items might be impacted by the current clean up.
[1] https://github.com/scottmarlow/jakartaee-tck/pull/3
[2] https://github.com/scottmarlow/jakartaee-tck/tree/tckrefactor_marlow_beforesquash
[3] https://github.com/scottmarlow/jakartaee-tck/tree/tckrefactor_marlow

Andrii, the Triber behind the development of the contributor's tool, found out the follow
Conclusion: Squash is not optimal to commit history with reference to the stats used for the tool.

Quoting Andrii: "the Tool for committers is pulling all PR and commit authors with co-authors. The only issue is if commit is improperly manually squashed (without co-author contribution), or commit history was forcibly rewritten, but it's more a question of development best practices and contribution, it is hard to fix through just having raw data. (there is no even indication it even existed in that branch)"

@Dexmaster, you are most welcomed to expand your findings and Q&A as needed.

Scott, questions, shoot!

Thanks for enabling this discussion :)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the referenced jakartaee-tck pull request and the before- and after-squash branches, then trace how commit and co-author data feeds the release-page contributor cards. Done requires an agreed handling for squash or rewritten history and a documented outcome for the contributor-card tool.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, github
Domain
release, tooling
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.