yegor256/rultor

Rultor should help create a better git log and release text

Open

#919 opened on Aug 14, 2015

View on GitHub
 (14 comments) (0 reactions) (0 assignees)Java (165 forks)github user discovery
bugenhancementhelp wanted

Repository metrics

Stars
 (575 stars)
PR merge metrics
 (PR metrics pending)

Description

Just look over this release example, it's nice to see something like:

  • #<issue1> <Description of Issue1>
  • #<issue2> <Description of Issue2>
  • ...

And for the git log, something like this:

  • Merge pull request #<issue> from <branch-name>
  • Fixes #<issue>: <Description of issue>
  • ...

Currently with rultor I see things like this in some releases:

  • <hash> by rultor: Merge branch '__rultor'
  • <hash> by @alxn: Some in-person review comments...
  • <hash> by @alxn: Update the UML started by...
  • <hash> by rultor: Merge remote-tracking branch '...
  • <hash> by rultor: Merge remote-tracking branch '...
  • <hash> by rultor: Merge branch '__rultor'
  • <hash> by <@user>: `: CR fixes more....
  • <hash> by <@user>: `: CR fixes....
  • <hash> by <@user>: `: cobertura....
  • <hash> by <@user>: `: checkstyle....
  • <hash> by <@user>: `: Fix for....
  • And the same in history.

I know squashing goes a long way to help this, but I think what we really want to see on master, and in the release notes is something more like:

  • <hash> by <@user1>: <issue1>: <Description of issue1>
  • <hash> by <@user2>: <issue2>: <Description of issue2>
  • <hash> by <@user3>: <issue3>: <Description of issue3>

Contributor guide

Research direction
Explore how Rultor generates release text and git log entries. Consider integrating with GitHub API to fetch issue descriptions and format commits accordingly. Look into existing git log formatting tools and implement a custom solution that groups commits by issue with descriptions.
Tech stack
java
Domain
devopstoolingrelease
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
Half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
Git
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
70