> On 18-May-2015, at 2:02 pm, Erik Weber <terbol...@gmail.com> wrote: > > 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. >
+1 This was sort of a unwritten rule that any commit should have a Jira id. That way it is easier to track across releases and also it is easier to know the what the commit is solving/fixing. > >>> - 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 Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
