I'm +1 on squashing and merging, but I think we need a combination of a number of things to really have a decent changelog. Even if we have awesome commit messages and squashed PRs, there's still way too many PRs in a release to just generate a decent changelog from the PR titles and/or commit messages. We still need a way to logically separate PRs into bugfixes, new features, breaking changes, etc. We could get some of that separation using github tags, but what if there are multiple PRs that compose one new high-level feature? At that point I think we'd have to create a new tag for every new high-level feature being worked on in order to group those PRs under the same heading. There's also the problem that only committers can tag issues, so it adds to the burden of committers to make sure all non-committer issues/PRs are properly tagged.
The main headache with doing a manually-curated changelog is the merge conflicts it causes, but I think we can easily avoid that problem by using a similar approach to reno [1] which breaks individual notes out into their own separate yaml files which are then parsed and merged into a single, cohesive changelog for each release. What that means is basically every logical bugfix/new feature/upgrade note gets its own file which avoids merge conflicts caused by just adding a line to the end of a CHANGELOG.md file every time. - Rawlin [1] https://docs.openstack.org/reno/latest/user/usage.html On Thu, Oct 18, 2018 at 1:45 PM Jeremy Mitchell <[email protected]> wrote: > > is there a setting in github to enable "squash and merge" vs "rebase and > merge"? > > i do have a couple of concerns however: > > 1. what happens when 2+ people contribute to a PR? This is a pretty common > scenario. If Bob and Sam both work on PR#1 is all the commit history for > Sam lost? > 2. i can see benefits of having granular history...to a point... > > The more I think about this. Why is squash needed? Commits are grouped by > PRs. Why isn't our change log just a list of PR merged since the last > release? If a PR represents a working unit (as it should), PR titles should > be sufficient, no? > > For example, this is what our internal release change log looks like. > > Changelog from 2526569a to 284555703 > ======================================== > > These changes are deployed in branch deploy-20181002. > > PR 2300: Add TO Go cachegroups/id/deliveryservices > 65e27d2cb7c12b25c97bc98b09ffa6577bb6e1ff: Add TO Go > cachegroups/id/deliveryservices (Robert Butts, May 18 2018) > 130baa85b122f2827621c98f9e87b3245e18d80b: Add TO Go cachegroups/dses > API test, client funcs (Robert Butts, Jun 28 2018) > 5197a2da7e323976d5404ce135ff8c42cbed64ef: Remove TO unused func > (Robert Butts, Sep 13 2018) > PR 2803: Add Traffic Ops Golang Steering Targets > 8ba7d24303d2b420d5059654f83a7154ff7a0703: Add TO Go > steering/id/targets (Robert Butts, Jul 10 2018) > 5ba9a3b40b59f6de2c40ad71c5a0a1a84d3acacf: Add TO API Tests for > steeringtargets (Robert Butts, Sep 11 2018) > eca0a7eab65cd37d6e4f0658c7640200b2e9ecda: Add TO Go client > steeringtarget funcs (Robert Butts, Sep 12 2018) > PR 2806: Add sub to validate user input when running postinstall script > e50eeb2c7f46828cbe1d461288f2d98ccdd4ebaa: Add sub to validate user > input when running postinstall script changes default cdn name to not > include an underscore. (Dylan Souza, Sep 11 2018) > 9ac409904987ad0b52e3de26b79422b9688bbb8e: Altering postinstall cdn > name regex to include underscores (Dylan Souza, Sep 21 2018) > 70d8893335b63db006974932341378717c42701c: Changing back the default > cdn name value (Dylan Souza, Sep 21 2018) > PR 2812: remove traffic_monitor_java > 4e7a7ab26cce0903ebe54dd0892da45feaf8d3de: remove traffic_monitor_java > (Dan Kirkwood, Sep 12 2018) > > > [truncated] > > > On Thu, Oct 18, 2018 at 9:52 AM Dave Neuman <[email protected]> wrote: > > > Well, our "curated" changelogs are missing A LOT of information on what > > actually went into the release, which therefore makes it not useful. If we > > were better about commit messages and used squash and merge, then we would > > at least have something for every PR that was merged. > > > > On Thu, Oct 18, 2018 at 8:25 AM Jan van Doorn <[email protected]> wrote: > > > > > > I think this just shifts the burden from writing a changelog entry to > > > writing a good commit entry. > > > > > > > > > I agree, and I think that’s where that burden belongs. (And I _really_ > > > hate merge conflicts). > > > > > > > There might be fewer commit entries if we squash and merge, but I’m > > > doubtful that it would be as valuable as our “curated” changelogs. > > > > > > Both are dependent on how disciplined we are. > > > > > > I’m +1 on Squash and Merge. > > > > > > Cheers, > > > JvD > > > > > > > > > > On Oct 18, 2018, at 08:18, Eric Friedrich (efriedri) > > > <[email protected]> wrote: > > > > > > > > I think this just shifts the burden from writing a changelog entry to > > > writing a good commit entry. > > > > > > > > There might be fewer commit entries if we squash and merge, but I’m > > > doubtful that it would be as valuable as our “curated” changelogs. > > > > > > > > > > > > > > > > > > > >> On Oct 18, 2018, at 9:40 AM, Dave Neuman <[email protected]> wrote: > > > >> > > > >> Hey All, > > > >> I want to follow up on something that was briefly discussed at the > > > summit > > > >> this week. Many people do not like the Changelog and feel like it can > > > be a > > > >> PITA to deal with. One of the reasons we have the changelog is > > because > > > >> there are so many commits in a given release, that it is hard to comb > > > >> through all of them to figure out what noteworthy changes or bug fixes > > > went > > > >> into the code. One thing that may help with this problem is to use > > > enable > > > >> the squash and merge feature on Github for pull requests [1]. This > > > >> feature would squash all commits in a PR into one commit. If we pair > > > the > > > >> one commit with a good commit message, we would essentially get the > > > ability > > > >> to create the changelog just from the commits. > > > >> > > > >> So, I would like to propose that we enable the squash and merge > > feature > > > in > > > >> the Traffic Control Github repo and use that going forward. Thoughts? > > > >> > > > >> Thanks, > > > >> Dave > > > >> > > > >> > > > >> [1] https://help.github.com/articles/about-pull-request-merges/ > > > > > > > > > > > >
