Hi Willy, On Wed, Nov 7, 2018 at 8:48 PM Willy Tarreau <[email protected]> wrote: > This case is very interesting because there is no easy answer. > Given that our changelogs are now automatically produced from > git log, I tend to think we'd rather not adjust them, because > their only use case is to either copy-paste the line from the > changelog and search it in "git log" to reach the commit, or > for stable branches, to look for a commit message coming from > an upstream branch. > > Thus I *tend* to think that fixing these changelogs would not > significantly help ut could add a bit of difficulty over time, > and I'd prefer to leave them as-is, at least for the git part. > Probably that the older parts are no more relevant by now so > I'm fine with any option.
Yes, that's often the problem. Some people fix this issue by adding the commit sha (long or short) at the beginning or end of the line (which is automatically detected if you're in markdown on github and transformed to a link if you want to be fancy! :) ). But I see your point. > However this outlines the importance of being extra careful > in the subject line of our commit messages and to adjust this > part when applying the patch if needed, which I used not to > do too often unless the description was unclear or misleading. > Maybe we should add a point in the CONTRIBUTING file about the > importance of caring about this point. There are some mention about being careful about typo in the section 5 about the documentation but it may be worth having a git hook that would warn about typos when creating a commit maybe? > Just thinking about something, how did you figure all these > typos ? By reading everything, or aided by some automated tool > or maybe a mix of all of this ? I'm asking in case we could try > to improve our tools to spot mistakes before and after patch > submissions. I saw some typos while reading the documentation so I ran misspell (https://github.com/client9/misspell) on it. There are some false positives sometimes with it so you have to re-read it carefully but it generally does a good job at detecting common typos. I generally use this one as it's a commonly used tool in the golang world when you care about linters but it's applicable in most text files. Right now misspell detects over 300 issues over the entire repo, not 100% fixable, but that was the point of https://github.com/haproxy/haproxy/pull/1 which I'll be breaking down in several patches when I got more time in the days to come. Joseph
