Cosmos-sdk: Why now editting CHANGELOG directly?

[ethanfrey]

Summary

There use to be some clog tool that we could use to enter changes in the PR in some .pending directory then forget about that until it was merged and collated upon release.

Recently, it seems the team has now gone back to directly editting the CHANGELOG. I updated my PR and now everytime I merge in master to ensure it is up to date, there is a merge conflict. Sure, it is not difficult to resolve, but it gets quite annoying.

Given there was a working solution for this issue, why did you go back to the direct CHANGELOG editing? I would love a good explanation, and maybe some way to mitigate the constant conflicts. I need to update CHANGELOG before submitting the PR to review, so doing that at the very end doesn't seem like a good solution either.

@fedekunze maybe you can answer?

[fedekunze]

Ref #4902 cc: @alexanderbez

It was removed because it didn't allow you to see all the list of changes cleanly on a single file. Also, it was a hustle for outside first time contributors (not your case) as they usually never created the .pending file so 1 line PRs were sitting there for a long time. We had to constantly ping them to remind them.

Updating the Changelog directly was the simplest solution to the problem.

[ethanfrey]

Thanks for the link on the PR. I see when the change happened, and the developer flow was properly updated. I was more wondering the reasoning behind it. Maybe you can update the description of the PR to contain the "why"?

It actually seem most PRs by core team have little to no context/explanation in the PR description, as you all know why. It helps follow the development flow for those outside just to add a paragraph explaining the purpose, as that is generally required for the rest of us. No need to justify yourself, just give reason and purpose to help follow.

[alexanderbez]

Great question @ethanfrey. The flow went from a canonical changelog => pending logs => back to canonical changelog. The "why" here is because the pending log added minimal benefit and introduced major headaches, specifically during the release process. The benefit was obviously no merge conflicts...yayy. The headaches resulted in being a huge PIA during the release process namely because you never get a holistic view of the log and merging chunks of the logs (per release) back into master was a nightmare. In addition, there were many duplicates. This is a process that was a real burden for me as I was the primary contributor performing releases.

To avoid conflicts as best as possible, placement in the log file is key although tricky. As a matter of fact, in the last few PRs that I've personally contributed to, I had zero conflicts in the log file.

It actually seem most PRs by core team have little to no context/explanation in the PR description, as you all know why. It helps follow the development flow for those outside just to add a paragraph explaining the purpose, as that is generally required for the rest of us. No need to justify yourself, just give reason and purpose to help follow.

Agree. Not to toot my own horn, but if you look at my PRs and issues, they're generally detailed and give appropriate context. However, this is not something I or we can enforce but rather must encourage amongst ourselves.

That being said, is there an actionable item you'd like to see out of this issue? If not, care to close?

[ethanfrey]

I can close this issue, it was more an open question.
Only actionable item would be to copy the first two paragraphs of your response onto the (closed) PR for posterity.

Also, maybe you can add a tip on how you get zero conflicts in the log file. If there is a trick to doing it, then I am definitely happy to adjust my workflow.

[alexanderbez]

Updated the PR @ethanfrey -- thank you.