Thanks, Alex, for moving this forward! When contributors report recurring friction, saying that others encounter it less often doesn't resolve the problem they're reporting. A more useful response is to identify a concrete drawback in the proposed solution, suggest an alternative, or agree to try it. That applies to my earlier suggestion to resolve conflicts in the GitHub UI as well: it offered a workaround, but didn't address the recurring overhead.
After re-reading the thread, I support trying the fragments approach to reduce the recurring changelog conflicts. So let's review the implementation and carefully test the assembly and cleanup logic in the PR. One point worth documenting now, even though it may become a problem only in a potential future: consuming a fragment for one release line must not consume it for another release line that still needs it. Propagating deletions back to the main branch can fit today's release arrangement, but with independent maintenance branches, main might still need those fragments for its next release. Robert On Tue, Nov 3, 2026 at 11:44 AM Alex Dutra via dev <[email protected]> wrote: > Hi Dmitri, Ayush, > > I went ahead and implemented the changelog.d feature using your design > suggestions: > > https://github.com/apache/polaris/pull/5967 > > PTAL. > > Thanks, > Alex > > On Fri, Oct 30, 2026 at 12:27 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > > Hi Alex, Ayush, > > > > I agree that the pain is real. > > > > My preference is also with option 1 (changelog.d). > > > > Proactive suggestion for file name pattern: > > changelog.d/<section>/NN-<short-title>.md > > > > The file should contain plain MD text suitable for inclusion in a list in > > the generated changelog. > > > > NN is the relative priority. Collisions are allowed and get resolve by > > <short-title>. Smaller numbers are listed higher in the final doc. > > > > Suggestion: use NNN=99 if priority is not critical. > > > > On release the included files are simply deleted from `main`. > > > > WDYT? > > > > Thanks, > > Dmitri. > > > > On Thu, Oct 29, 2026 at 12:30 PM Ayush Saxena <[email protected]> > wrote: > > > > > Thanks for restarting this thread, Alex. > > > > > > Regarding Option 2: I tested it, but it isn't working on my end. Even > > > if it did, it would be difficult to enforce since it requires > > > educating the team on the new process. > > > > > > Option 1 looks like the best approach to me, once we finalize the > > > naming conventions and the release script. > > > > > > -Ayush > > > > > > On Thu, 29 Oct 2026 at 21:51, Alex Dutra <[email protected]> wrote: > > > > > > > > Hi all, > > > > > > > > I'm reviving this thread because the pain is real :-) > > > > > > > > Can we agree on _something_ that would get rid of constant > conflicts? > > > > > > > > To summarize the options discussed thus far: > > > > > > > > 0. No curated changelog file at all > > > > - Pros: the file and its conflicts go away. No author effort. > > > > - Cons: The release notes are mostly a git log that few users read. > > > > Non-breaking user-facing notes and upgrade caveats aren't captured. > > > > > > > > 1. changelog.d/ fragments (one small file per PR, merged into > > > > CHANGELOG.md at release) > > > > - Pros: no shared lines, so no conflicts. Entries can be fixed after > > > > merge. Reviewers can comment line by line. Fragments carry over into > > > > cherry-picks. > > > > - Cons: filename scheme to settle (PR numbers aren't known upfront). > > > > Needs a RAT exclusion. Needs a release script. > > > > > > > > 2. Keep CHANGELOG.md and resolve conflicts in the GitHub UI > > > > - Pros: no process change. Resolving takes a few seconds and needs no > > > > re-approval. > > > > - Cons: CI re-runs on every merge commit. The friction stays. > > > > > > > > 3. Generate the release notes with AI at release time > > > > - Pros: little author effort. > > > > - Cons: it can silently omit breaking changes. Output isn't > > > > reproducible for release votes. AI can't surface caveats that nobody > > > > wrote down. > > > > > > > > 4. Changelog text in commit messages > > > > - Pros: no extra files. Works with cherry-picks. > > > > - Cons: CI can't enforce it. The merger can overwrite the author's > > > > text. GitHub's default message pulls in unrelated text. Editing it > > > > after a long review is heavy. > > > > > > > > 5. PR label plus a CHANGELOG comment, assembled at release > > > > - Pros: no files in the repo. > > > > - Cons: entries live in PR comments, so they're hard to review or > fix. > > > > It depends on a release workflow that scrapes GitHub. > > > > > > > > What do you all prefer? > > > > > > > > Thanks, > > > > Alex > > > > > > > > On Wed, Oct 7, 2026 at 10:53 PM vignesh a <[email protected]> > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > +1 on Yufei's approach first [5733]. > > > > > > > > > > Tightening the guidance so CHANGELOG only covers changes worth > > > > > calling out in release notes should cut a lot of the contention. > > > > > That matches how Dimitri described the original intent. > > > > > > > > > > If we still collide often after that, I'm fine moving to Alex's > > > > > changelog.d idea as the next step. > > > > > > > > > > Thanks > > > > > Vignesh > > > > > > > > > > [5733] https://github.com/apache/polaris/pull/5733 > > > > > > > > > > On Thu, 8 Oct 2026 at 00:35, Dmitri Bourlatchkov <[email protected] > > > > > wrote: > > > > > > > > > > > Hi Yufei, > > > > > > > > > > > > Thanks for raising PR [5733]. I think it makes sense. Let's see > how > > > it > > > > > > works out. > > > > > > > > > > > > [5733] https://github.com/apache/polaris/pull/5733 > > > > > > > > > > > > Cheers, > > > > > > Dmitri. > > > > > > > > > > > > On Wed, Oct 7, 2026 at 2:31 PM Yufei Gu <[email protected]> > > > wrote: > > > > > > > > > > > > > Dmitri’s clarification helps: we don’t need an entry for every > PR, > > > > > > > only changes worth calling out to users. I made the same point > in > > > my > > > > > > > previous email. I hope this will significantly reduce merge > > > conflicts. > > > > > > > We could give it a try, and if conflicts are still there, we > can > > > adopt > > > > > > > Alex ’s changelog.d proposal. WDYT? > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 7, 2026 at 7:04 AM Jean-Baptiste Onofré < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I am fine with whichever approach the team decides. > > > > > > > > > > > > > > > > However, I personally am not convinced that maintaining a > > > CHANGELOG is > > > > > > > > necessary. In my view, the maintenance effort outweighs the > > > actual > > > > > > value > > > > > > > it > > > > > > > > provides. > > > > > > > > Just my two cents. > > > > > > > > > > > > > > > > Regards, > > > > > > > > JB > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 7, 2026 at 3:45 PM Dmitri Bourlatchkov < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > One more "plus" to Alex's proposal: > > > > > > > > > > > > > > > > > > * Files-based changelog entries can be corrected after the > > > original > > > > > > PR > > > > > > > and > > > > > > > > > before the release. > > > > > > > > > > > > > > > > > > I believe we have a few cases where, as a feature was > > > developing, its > > > > > > > > > change log entry evolved too (I do not have the example off > > > the top > > > > > > of > > > > > > > my > > > > > > > > > head, but I'm pretty sure it was real). > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > On Wed, Oct 7, 2026 at 9:33 AM Alex Dutra < > [email protected]> > > > wrote: > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > Robert's proposal is also interesting: it keeps the > > > discipline but > > > > > > > > > > eliminates the need for changelog fragment files. But > again > > > there > > > > > > > > > > might be tradeoffs to consider: > > > > > > > > > > > > > > > > > > > > 1) CI cannot enforce that the final commit message will > > > contain a > > > > > > > > > > valid changelog entry. > > > > > > > > > > > > > > > > > > > > 2) the person who merges the PR is not necessarily the > PR's > > > author, > > > > > > > so > > > > > > > > > > we would need to be careful not to override the author's > > > changelog > > > > > > > > > > text when merging. > > > > > > > > > > > > > > > > > > > > 3) If the PR contains many commits, GitHub by default > > > accumulates > > > > > > > > > > messages from all commits as the default merge commit > > > message, so > > > > > > we > > > > > > > > > > would need to be careful that unrelated text from other > > > commits in > > > > > > > the > > > > > > > > > > PR won't show up in the changelog by mistake. > > > > > > > > > > > > > > > > > > > > After considering this, I think I still prefer the > > > changelog.d > > > > > > > approach. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > On Wed, Oct 7, 2026 at 2:21 PM Jean-Baptiste Onofré < > > > > > > [email protected] > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Yes, that's a good idea. > > > > > > > > > > > > > > > > > > > > > > I'm not a big fan of the GH release ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes#example-configurations > > > > > > > > > > ), > > > > > > > > > > > but we can mimic a bit as Robert proposed. > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > JB > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 7, 2026 at 2:13 PM Robert Stupp < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > I think, as an alternative, we could phrase the > merged > > > commit > > > > > > > > > messages > > > > > > > > > > to > > > > > > > > > > > > be suitable for CHANGELOG entries. > > > > > > > > > > > > Assuming we'd choose to go with > > > conventional-commit-messages > > > > > > > rules, a > > > > > > > > > > > > relatively simple `git log` with appropriate > formatting > > > rules > > > > > > > could > > > > > > > > > be > > > > > > > > > > used > > > > > > > > > > > > to generate the CHANGELOG and release-notes content. > > > > > > > > > > > > This would also work when commits are cherry-picked > onto > > > > > > > > > > release-branches, > > > > > > > > > > > > and we wouldn't need to look up PR content via > GItHub API > > > > > > > requests. > > > > > > > > > > > > > > > > > > > > > > > > Either approach requires discipline from the PR > author > > > and/or > > > > > > > > > committer > > > > > > > > > > > > regarding the merged commit messages and/or PR > content. > > > > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 7, 2026 at 2:03 PM Jean-Baptiste Onofré < > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > > > > > > > > > I would go with something simpler for now. > > > > > > > > > > > > > > > > > > > > > > > > > > 1. A PR is flagged with changelog label (in > addition > > > of the > > > > > > > > > > milestone). > > > > > > > > > > > > > 2. This PR contains a comment (hand written) > starting > > > with > > > > > > > > > > "**CHANGELOG** > > > > > > > > > > > > > ...". > > > > > > > > > > > > > 3. As part of the release workflows, we create the > > > CHANGELOG > > > > > > > for a > > > > > > > > > > > > release > > > > > > > > > > > > > by assembling the **CHANGELOG** comment from PRs > in the > > > > > > > milestone > > > > > > > > > > > > > > > > > > > > > > > > > > No need to have AI, curated comments and assembly > > > ad-hoc with > > > > > > > this > > > > > > > > > > > > > mechanism. > > > > > > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > Happy to make a draft about this :) > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > JB > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 7, 2026 at 1:11 PM Alex Dutra < > > > [email protected] > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > As I recall, the main reason for maintaining a > > > manually > > > > > > > curated > > > > > > > > > > > > > > changelog was to offer a clear, thoughtful > summary of > > > > > > release > > > > > > > > > > changes > > > > > > > > > > > > > > – a task that automated tools traditionally > > > struggled with. > > > > > > > > > > > > > > > > > > > > > > > > > > > > With recent advancements in AI, we could consider > > > > > > revisiting > > > > > > > this > > > > > > > > > > > > > > stance and exploring an AI-assisted workflow, as > > > Yufei > > > > > > > proposed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > That said, I think we should consider these > tradeoffs > > > > > > > carefully > > > > > > > > > > before > > > > > > > > > > > > > > making such a decision: > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Missing context: the most essential parts of > our > > > > > > > changelogs are > > > > > > > > > > the > > > > > > > > > > > > > > highlights and upgrade notes, e.g. the > > > rolling-upgrade > > > > > > > caveat for > > > > > > > > > > > > > > credentialVendingMechanism. Since details like > this > > > aren't > > > > > > > > > > captured in > > > > > > > > > > > > > > PR titles or code diffs, an LLM model can only > > > include them > > > > > > > if an > > > > > > > > > > > > > > author explicitly documented them somewhere. > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Silent omissions: if an LLM accidentally omits > a > > > breaking > > > > > > > > > change, > > > > > > > > > > > > > > the resulting output still appears plausible, > making > > > it > > > > > > > difficult > > > > > > > > > > for > > > > > > > > > > > > > > a release manager to identify what's missing. > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Non-deterministic output: because LLM-generated > > > text > > > > > > isn't > > > > > > > > > > directly > > > > > > > > > > > > > > reproducible from the repository state, every > > > execution > > > > > > > produces > > > > > > > > > a > > > > > > > > > > > > > > slightly different changelog, which could be an > > > issue for > > > > > > > > > official > > > > > > > > > > > > > > release votes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Given these points, requiring PR authors to > submit > > > > > > changelog > > > > > > > > > > entries > > > > > > > > > > > > > > when relevant remains imho a valuable discipline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Moving to a changelog.d directory structure > should > > > > > > > effectively > > > > > > > > > > address > > > > > > > > > > > > > > the pain around merge conflicts and reduce > > > contention on > > > > > > > > > > CHANGELOG.md. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Oct 6, 2026 at 8:18 PM Dmitri > Bourlatchkov < > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When I originally proposed the CHANGELOG file > [1], > > > the > > > > > > > idea was > > > > > > > > > > to > > > > > > > > > > > > help > > > > > > > > > > > > > > > with itemizing the changes at release time :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It was never meant to include an entry for > every > > > small > > > > > > PR, > > > > > > > only > > > > > > > > > > for > > > > > > > > > > > > PRs > > > > > > > > > > > > > > > worth mentioning in release notes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Alex's idea of "/changelog.d" sounds > interesting. I > > > > > > > suppose if > > > > > > > > > we > > > > > > > > > > > > name > > > > > > > > > > > > > > > those files according to to the date, we'll > > > automatically > > > > > > > get a > > > > > > > > > > > > sorted > > > > > > > > > > > > > > > change log for release notes. We could probably > > > also use > > > > > > a > > > > > > > > > > pattern or > > > > > > > > > > > > > > > textual tags to identify breaking changes, > fixes, > > > etc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re: conflict resolution via UI, I think a tool > > > plus some > > > > > > PR > > > > > > > > > > > > discipline > > > > > > > > > > > > > is > > > > > > > > > > > > > > > preferable to a manual process. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > https://lists.apache.org/thread/qznf8toht1r7ml35lt4p8nwlk9op638v > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Oct 6, 2026 at 1:35 PM Jean-Baptiste > > > Onofré < > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To play devil's advocate: do we really need a > > > CHANGELOG > > > > > > > file? > > > > > > > > > > :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that we need to inform users about > > > breaking > > > > > > > changes > > > > > > > > > and > > > > > > > > > > > > > > user-facing > > > > > > > > > > > > > > > > updates. However, we could simply use a > > > > > > "breaking-change" > > > > > > > > > > label on > > > > > > > > > > > > > > GitHub > > > > > > > > > > > > > > > > PRs and automatically populate the Release > Notes > > > at > > > > > > > release > > > > > > > > > > time, > > > > > > > > > > > > > > rather > > > > > > > > > > > > > > > > than manually maintaining a CHANGELOG. The > > > remainder > > > > > > of a > > > > > > > > > > typical > > > > > > > > > > > > > > CHANGELOG > > > > > > > > > > > > > > > > is essentially just a git log, which most > users > > > do not > > > > > > > read > > > > > > > > > > > > anyway. I > > > > > > > > > > > > > > have > > > > > > > > > > > > > > > > successfully used this approach across > several > > > ASF > > > > > > > projects. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > JB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Oct 6, 2026 at 7:08 PM Ayush Saxena < > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Everyone, > > > > > > > > > > > > > > > > > +1 on trying to find some way around > solving > > > > > > CHANGELOG > > > > > > > > > > conflicts. > > > > > > > > > > > > > > Some > > > > > > > > > > > > > > > > > numbers in case they help make the case: > over > > > the > > > > > > last > > > > > > > 60 > > > > > > > > > > days, > > > > > > > > > > > > 75 > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > 339 commits on main touched CHANGELOG.md — > > > roughly > > > > > > one > > > > > > > in > > > > > > > > > > four > > > > > > > > > > > > and > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > half. Every one of those is a potential > > > conflict with > > > > > > > every > > > > > > > > > > > > other, > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > none of them is a real logical conflict. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Yufei's two points: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ASF headers — I don't think fragments need > > > them. rat > > > > > > > > > already > > > > > > > > > > has > > > > > > > > > > > > an > > > > > > > > > > > > > > > > > exclusion list in build.gradle.kts (the > > > RatTask block > > > > > > > > > around > > > > > > > > > > line > > > > > > > > > > > > > > 55), > > > > > > > > > > > > > > > > > and it already excludes a Markdown file on > > > exactly > > > > > > > these > > > > > > > > > > grounds: > > > > > > > > > > > > > > > > > .github/pull_request_template.md. Adding > > > > > > > changelog.d/** is > > > > > > > > > > one > > > > > > > > > > > > > line. > > > > > > > > > > > > > > > > > Worth double checking though — but they > never > > > ship > > > > > > in a > > > > > > > > > > release > > > > > > > > > > > > > > > > > artifact, since they're consumed and > deleted > > > before > > > > > > > the RC > > > > > > > > > is > > > > > > > > > > > > cut, > > > > > > > > > > > > > so > > > > > > > > > > > > > > > > > I think ASF header isn't required. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Multi-PR features — this gets easier rather > > > than > > > > > > > harder. > > > > > > > > > > Today a > > > > > > > > > > > > > > > > > follow-up has to edit shared lines in > > > CHANGELOG.md; > > > > > > > with > > > > > > > > > > > > fragments > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > > edits or deletes one file its own feature > > > owns, so > > > > > > > > > follow-ups > > > > > > > > > > > > stop > > > > > > > > > > > > > > > > > colliding with unrelated work. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One thing worth settling in the PR: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Naming. changelog.d/pr-1235.md has a > > > chicken-and-egg > > > > > > > > > > problem: you > > > > > > > > > > > > > > > > > don't know the PR number until the PR > exists, > > > so the > > > > > > > first > > > > > > > > > > push > > > > > > > > > > > > > never > > > > > > > > > > > > > > > > > has the right name. Allowing a short slug > > > > > > > > > > > > > > > > > (changelog.d/ranger-implied-grants.md), or > > > keying off > > > > > > > the > > > > > > > > > > issue > > > > > > > > > > > > > > number > > > > > > > > > > > > > > > > > where one exists, avoids the extra round > trip. > > > > > > > towncrier's > > > > > > > > > > > > > convention > > > > > > > > > > > > > > > > > is <issue>.<type>.md with a +<slug>.md > escape > > > hatch > > > > > > for > > > > > > > > > > changes > > > > > > > > > > > > > with > > > > > > > > > > > > > > > > > no issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Robert's point changes my view somewhat. If > > > resolving > > > > > > > in > > > > > > > > > the > > > > > > > > > > UI > > > > > > > > > > > > > > > > > doesn't dismiss the approval, the > per-conflict > > > cost > > > > > > is > > > > > > > much > > > > > > > > > > lower > > > > > > > > > > > > > > than > > > > > > > > > > > > > > > > > I assumed. The one cost it does leave is > CI: > > > that > > > > > > merge > > > > > > > > > > commit > > > > > > > > > > > > > > re-runs > > > > > > > > > > > > > > > > > the entire pipeline for a one-line docs > > > change.This > > > > > > > mostly > > > > > > > > > > should > > > > > > > > > > > > > be > > > > > > > > > > > > > > > > > solvable, that we don't trigger the entire > CI > > > flow > > > > > > > when the > > > > > > > > > > > > change > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > only in the CHANGELOG. With that plus a > line > > > in the > > > > > > PR > > > > > > > > > > template > > > > > > > > > > > > > about > > > > > > > > > > > > > > > > > resolving in the UI, I think the lighter > > > option is a > > > > > > > > > genuine > > > > > > > > > > > > > > > > > alternative to the fragment directory > rather > > > than > > > > > > just > > > > > > > a > > > > > > > > > > stopgap. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Ayush > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 6 Oct 2026 at 22:23, Robert Stupp < > > > > > > > [email protected]> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
