That is called a commit message. It could be a joke but I am serious. The first exerpt-like line should read exactly what you are describing.
On Tue, 19 May 2015 10:08 Sebastien Goasguen <run...@gmail.com> wrote: > > > On May 19, 2015, at 9:59 AM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > > > I must urge not to try to maintain a changelog by hand. > > > I should not have used the term changelog. > > I am used to do this in libcloud: > > https://github.com/apache/libcloud/blob/trunk/CHANGES.rst > > it’s just a good habit. You make a commit, you write a line in the file, > with a pointer to the PR or the JIRA bug and a short description. > > It saves having to struggle for changes at release time (jira filters seem > to break etc and not everything gets to JIRA…as we are discussing) > > So I am not asking for an overly complex process, I am just saying: > > -when you commit something, you write a one line in a text file with a ref > to somewhere - > > > > -seb > > > it is error prone > > and if people follow Erik's guideline of giving reason in a commit > message > > creating one from the git log becomes easy. It will be a matter of > deleting > > the irrelevant from the git log output. > > > > Op di 19 mei 2015 om 09:53 schreef Rohit Yadav < > rohit.ya...@shapeblue.com>: > > > >> Hi, > >> > >> I think having JIRA references for bug tickets is useful for tracking > >> fixes and should be encouraged, though for minor fixes it may be > avoided. > >> > >> I also like the idea of maintaining the changelog every time a developer > >> adds a new change instead of updating it at the time of release. > >> > >> I guess, without introducing a rule, we should encourage a guideline to > >> encourage better commit messages, jira references, people updating > >> changelog frequently and squashing large number of commits or merging as > >> branch instead of fast forward merge. > >> > >> IMO I feel I’m seeing more important changes in recent months (such as > >> more PRs, people waiting on Travis to go green, a lot of refactoring > work > >> and bugfixes) and don’t want to see anything applied that adds > significant > >> overhead in terms of developer/contributor/reviewer time. > >> > >> About PRs: In the past, I have had to do extra work to find the source > >> repository and then add it as remote on my local git repo and then do > the > >> merge. So, if you’re a committer please push the branch on asf origin > and > >> send PR using that asf origin/branch which could make merging branches > >> easier. > >> > >> Nowadays to speed up reviewing, once I’m done reviewing a PR I use a git > >> alias to which I give the github pr link and it automatically commits > the > >> patch: > https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig#L46 > >> (Usage: git pr :url). > >> > >>> On 18-May-2015, at 10:39 am, Sebastien Goasguen <run...@gmail.com> > >> wrote: > >>> > >>> I am also in favor of text changelog in the root. > >>> > >>> Creating JIRA for everything may lead to bad tickets anyway. > >>> > >>> What is also nice is a quick changelog. The habit would be for everyone > >> to remember to update the change log when they do a commit (and agree > on a > >> format for it)... > >>> > >>> > >>> > >>>> On May 18, 2015, at 11:27 AM, Wilder Rodrigues < > >> wrodrig...@schubergphilis.com> wrote: > >>>> > >>>> Okay, > >>>> > >>>> +1 for create the ACS Jira issue for improvements as well. > >>>> > >>>> Since Xen and Libvirt redesign will be on 4.6 - and are already > >> documented - I will just create 2 issues so we have a way of keeping > track > >> of them. > >>>> > >>>> Cheers, > >>>> Wilder > >>>> > >>>> > >>>> On 18 May 2015, at 11:16, Stephen Turner <stephen.tur...@citrix.com > >> <mailto:stephen.tur...@citrix.com>> wrote: > >>>> > >>>> Speaking for my XenCenter team again, for things like that we would > >> have an improvement ticket, pointing to the wiki page. > >>>> > >>>> By the way, this also allows us to schedule the work on our sprint, > but > >> we had the policy even before we were doing Scrum. In a large, > distributed, > >> volunteer organisation, I would argue that it's even more important to > be > >> able to trace the change back to its reason, now and later. > >>>> > >>>> -- > >>>> Stephen Turner > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com] > >>>> Sent: 18 May 2015 10:11 > >>>> To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> > >>>> Subject: Re: Preparing for 4.6 > >>>> > >>>> Hi there, > >>>> > >>>> I agree with the Jira ticket for the "new features, important fixes, > >> security fixes" > >>>> > >>>> But I don’t think only about "new features, important fixes, security > >> fixes”. I put most of my time in make the code better and tested, for > what > >> we call refactoring/rewriting/redesigning. Should we also create Jira > >> issues for that and mark them as Improvement? > >>>> > >>>> Taking into account the [VPC] Virtual Router, Citrix Resource Base and > >> Libvirt Computing Resource refactoring, we had only internal issues on > >> Jira. However, the changes have been documented on the 4.5/4.6 sections > of > >> the Apache / Developers / Design Documents wiki: > >>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation > >>>> > >> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin > >>>> > >>>> The Libvirt documentation is on its way, since the PR was pushed only > >> last week. > >>>> > >>>> Cheers, > >>>> Wilder > >>>> > >>>> > >>>> On 18 May 2015, at 10:39, Stephen Turner <stephen.tur...@citrix.com > >> <mailto:stephen.tur...@citrix.com><mailto:stephen.tur...@citrix.com>> > >> wrote: > >>>> > >>>> In my XenCenter dev team at Citrix, we have the policy of requiring a > >> ticket number on every commit. If we find a bug and there isn't already > a > >> ticket, we create a ticket before committing the fix. I guess I've just > dug > >> through history too many times to understand why something that appears > >> wrong was done, only to find an inadequate description at the end of the > >> trail. > >>>> > >>>> -- > >>>> Stephen Turner > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Erik Weber [mailto:terbol...@gmail.com] > >>>> Sent: 18 May 2015 09:32 > >>>> To: dev > >>>> Subject: Re: Preparing for 4.6 > >>>> > >>>> On Mon, May 18, 2015 at 10:26 AM, Rene Moser <m...@renemoser.net > >> <mailto:m...@renemoser.net><mailto: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://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2 > >>>> d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid > >>>> QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh > >>>> PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F > >>>> > >>>> - 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 > >>>> > >>> > >> > >> Regards, > >> Rohit Yadav > >> Software Architect, ShapeBlue > >> M. +91 88 262 30892 | rohit.ya...@shapeblue.com > >> Blog: bhaisaab.org | Twitter: @_bhaisaab > >> > >> > >> > >> 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. > >> > >
