CHANGELOG.md entries are usually resolvable via the GH UI. I did that today and it only required removing three Git conflict marker lines in total. That ended in a "merge" commit generated by GH that didn't even require another approval of the PR.
On Tue, Oct 6, 2026 at 6:41 PM Yufei Gu <[email protected]> wrote: > Hi Alex, > > Thanks for raising this point, it is definitely a pain point. > > To address it, I think we could create a file named after the PR number, > such as changelog.d/pr-1235.md. > > A few overhead items and concerns to consider: > > 1. ASF Headers: New files will require ASF headers. While this is a bit > verbose, it should be fine. > 2. Multi-PR Features: We may need to update the changelog when a feature > is split across multiple small PRs. We could allow follow-up PRs to modify > or even remove the changelog entry created by a previous PR. It should be > fine as well. > > I'm open to other ideas as well. > > Yufei > > > On Tue, Oct 6, 2026 at 9:05 AM Alex Dutra <[email protected]> wrote: > > > Hi all, > > > > Almost every PR that touches user-facing behavior adds an entry under > > "## [Unreleased]" in CHANGELOG.md. Since all of those PRs edit the > > same few lines, they regularly conflict with each other. Contributors > > and reviewers then spend time rebasing and re-resolving a file that > > has no real logical conflicts. > > > > I'd like to propose a process change that removes this problem: > > instead of editing CHANGELOG.md directly, each PR adds its own small > > file under a new changelog.d/ directory. Because two PRs never edit > > the same file, they can't conflict. At release time, a script > > assembles the fragments into CHANGELOG.md and deletes them. > > > > What do you think? If you like the idea, I can draft a PR and flesh > > out the details. > > > > Thanks, > > Alex > > >
