On Mon, May 18, 2015 at 10:26 AM, Rene Moser <m...@renemoser.net> wrote:
> Hi > > On 15.05.2015 11:27, Sebastien Goasguen wrote: > > Folks, > > > > As we prepare to try a new process for 4.6 release it would be nice to > start paying attention to master. > > > > - Good commit messages > > The question is, what makes a commit message good? Maybe this helps: > > http://chris.beams.io/posts/git-commit/ > > > - Reference to a JIRA bug > > Must there be a JIRA bug? I did some commits without jira bugs in the > past. But I noticed that those are not "tracked" in the changelog of the > new release. So should there be a policy (is there?) that there must be > a jira bug for fixes? > > I believe there should be a JIRA bug for most things. JIRA is a good place to document why you're doing something, it's also easy to use as a source for release notes as you discovered. It's also good practice to document bugs/fixes, it's generally easier to find JIRA bugs than it is to find commit messages - especially for non-developers / newbies. For major code commits (new features, important fixes, security fixes) I'd say it should be a requirement, but I don't know if it already is or not. > > - Squashing commits ( cc/ wilder :)) > > This really depends. I would not generally prefer squashing commits. > > The example of > https://github.com/apache/cloudstack/commits/master?page=2 is more an > example of "bad" commit messages. > > If you look at the commits, they make sense but the commit message > indicates that they cover similar work in different aspects, which they > actually don't. > > But if you look at this example here > > https://github.com/ansible/ansible-modules-extras/commits/devel?author=gregdek > where you can see dozens of similar commits, those should be squashed. > > +1 to squashing related commits where it makes sense to do so -1 to a general rule of squashing the whole PR -- Erik
