> 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) > <efrie...@cisco.com.INVALID> 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 <neu...@apache.org> 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/ >
