lattner added a comment. This is awesome, I agree completely we should curate release notes better. That said, I think this should make it more clear that there is a "difference in kind" between user-facing tools like clang/lldb etc and other libraries in LLVM. We don't want release note burden (or noise) for every little thing going into the optimizer or codegen. Do you think it would make sense to point out that this is about user-facing tools?
================ Comment at: llvm/docs/DeveloperPolicy.rst:195 +* Adding, removing, or regrouping a diagnostic. +* Fixing a bug (please link to the issue fixed in the bug database). +* Adding or removing an optimization. ---------------- aaron.ballman wrote: > nikic wrote: > > I disagree with this point. Bug fixes should not make it into the release > > notes as a matter of course -- there may be specific high-impact bug fixes > > that may be worth mentioning, but bug fixes should not be included in the > > release notes as a matter of policy. > > > > I agree that release notes for Clang/LLVM are currently insufficient, but > > we should also be careful not to over-compensate in the other direction, > > but including too much irrelevant noise. > > I disagree with this point. Bug fixes should not make it into the release > > notes as a matter of course -- there may be specific high-impact bug fixes > > that may be worth mentioning, but bug fixes should not be included in the > > release notes as a matter of policy. > > I disagree (quite strongly) with this and would point out that users have > explicitly requested this information be included: > https://discourse.llvm.org/t/rfc-update-developer-policy-on-release-notes/61856/3 > > > I agree that release notes for Clang/LLVM are currently insufficient, but > > we should also be careful not to over-compensate in the other direction, > > but including too much irrelevant noise. > > Bug fixes are generally far from irrelevant, but I agree that reviewer and > author discretion is advised (as with any release note). For example, if you > introduce a bug in version N and fix the bug in version N, there's no need > for a release note in that situation because there's no user-facing change as > far as users care about. But I don't want to try to spell that out in precise > detail because there will always be edge cases. I agree with both of you - listing every bug report would be too noisy and pretty irrelevant for most users, but there are high impact ones that are important and valuable to list. How about wording this bullet something like: * Fixing high impact bugs, e.g. ones that get discussed on hackernews or comparable forums (please link to the issue fixed in the bug database). ================ Comment at: llvm/docs/DeveloperPolicy.rst:196 +* Fixing a bug (please link to the issue fixed in the bug database). +* Adding or removing an optimization. +* Modifying a C stable API. ---------------- This is also too broad IMO, we don't want every new instcombine listed. I'd recommend making this more user-centric, e.g. "Adding or removing optimizations that have widespread impact or enables new programming paradigms" CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123957/new/ https://reviews.llvm.org/D123957 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
