<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 1, 2020 at 1:33 AM James Henderson <<a href="mailto:jh7370.2008@my.bristol.ac.uk">jh7370.2008@my.bristol.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Great, thanks for all the advice. I'm going to try to start writing release notes as I go/encourage people to do so in the areas I work in then.</div><div><br></div><div>On the commit versus Phabricator reference, my personal preference is the former, for similar reasons to David Blaikie, but I can be persuaded otherwise.</div><div><br></div><div>On back-porting, I would have thought that a release note got updated in the same commit as the fix, that would be good? That would mean the release note would make its way into the release note for the given local version of the tree, and would therefore more accurately reflect what was in that particular downstream version of LLVM.<br></div></div></blockquote><div><br>I think the only problem then would be that the release note would end up both in the impending release /and/ the next release? (but I forget exactly how the release notes document is structured (yeah, the document gets emptied after the branch - so that new notes relate only to the next release)) - so I think if a patch including release notes got cherry picked, you'd want to then commit a follow-up on mainline to delete that release note, since it's now going to appear in the impending release and shouldn't also appear in the release after that.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 30 Apr 2020 at 20:01, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 30, 2020 at 11:57 AM Fangrui Song <<a href="mailto:maskray@google.com" target="_blank">maskray@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-04-30, Robinson, Paul via llvm-dev wrote:<br>
>For the tools (which I know is mostly what James works on) I’d say new command-line options are worth release-noting as a way to advertise their existence.<br>
><br>
>From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of David Blaikie via llvm-dev<br>
>Sent: Thursday, April 30, 2020 11:47 AM<br>
>To: James Henderson <<a href="mailto:jh7370.2008@my.bristol.ac.uk" target="_blank">jh7370.2008@my.bristol.ac.uk</a>><br>
>Cc: LLVM Developers Mailing List <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
>Subject: Re: [llvm-dev] What is the process for release notes for LLVM<br>
><br>
>Eh - I'd say "Big" new features (hey, LLVM supports DWARFv5, or Split DWARF, or DWARF type units, or DWARF compression (though I don't think I wrote any release notes for several of those features that I implemented)).<br>
><br>
>I wouldn't bother release noting changes in output format for tools we don't consider to have stable output, or changes in robustness/better error handling/reporting as a broad thing - if there's some specific goal reached (llvm-dwarfdump is now X days fuzzer-clean & provides more informative error messages about failures) that might be worth noting, imho.<br>
<br>
Maybe a brief sentence like `Diagnostics messages have improved` is sufficient.<br>
I did this for <a href="https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html#elf-improvements" rel="noreferrer" target="_blank">https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html#elf-improvements</a><br>
(Thanks to Peter Smith who revised my wording)<br>
<br>
>FileCheck/lit/yaml2obj - if you like.<br>
><br>
>I suspect "too many release notes" is probably a problem that would be novel/worth having, so if you want to write more, perhaps do so I & if it seems like too many, we can cut back/retune.<br>
<br>
Looking at<br>
<a href="https://releases.llvm.org/10.0.0/docs/ReleaseNotes.html" rel="noreferrer" target="_blank">https://releases.llvm.org/10.0.0/docs/ReleaseNotes.html</a><br>
<a href="https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html" rel="noreferrer" target="_blank">https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html</a><br>
most items don't include a link to Dxxxxx.<br>
A user needs some log grepping to find the particular differential revisions.<br>
<br>
Where possible, I hope we include a link.  I added Dxxxx links for lld<br>
10.0.0 ELF items <a href="https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html#elf-improvements" rel="noreferrer" target="_blank">https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html#elf-improvements</a><br>
(In my opinion Dxxxxx is better than rGxxxxxx because Dxxxxx includes<br>
  discussions and can save an interested user a hyperlink click.)<br></blockquote><div><br>FWIW, I'd tend to prefer the source control reference - it's authoritative/all commits have one/etc.<br><br>& ideally if we did a better job of committing release notes with the actual change that they're noting - then the commit log for the changelog will help identify the relevant commit for more context on a decision, details on how it's implemented, etc.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>On Thu, Apr 30, 2020 at 1:57 AM James Henderson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
>Okay, thanks both, that's useful to know/think about.<br>
><br>
>I guess it doesn't really answer my question of "when is a release note appropriate"? I've seen in different software release notes that range from one per change, even if not user-facing, all the way to almost none at all, and I'm not sure where to draw the balance (aside from if the release manager wants one, add it). For example, should we add release notes if the error diagnostics from a tool change (text updates/quantity/warnings->errors or vice versa/etc)? Should all new options have an accompanying release note? What about format changes to llvm binutils output? And which tools should we be producing release notes for? Should they exist for FileCheck, lit or yaml2obj even though these are primarily intended for our internal testing?<br>
><br>
>On Wed, 29 Apr 2020 at 15:49, Sam Elliott <<a href="mailto:selliott@lowrisc.org" target="_blank">selliott@lowrisc.org</a><mailto:<a href="mailto:selliott@lowrisc.org" target="_blank">selliott@lowrisc.org</a>>> wrote:<br>
>This approximately follows my understanding and expectation.<br>
><br>
>I think that, if you have commit access, commits to improve release notes fall under the contribution guidelines for documentation and therefore do not require a full Phabricator review.<br>
><br>
>I know Alex Bradbury tries to coordinate the RISC-V backend-related release notes based on the backend changes since the last release, and this seems to work well (in some cases soliciting notes, in some cases just writing up what others had done). It does seem that role should not just fall on the shoulders of a backend or component owner, though.<br>
><br>
>I would agree that it could be easier to update release notes in patches that make the changes to keep everything together, although I'm not sure how this affects backporting patches (solving merge conflicts in release notes seems like it could be rather infuriating if it happened a lot).<br>
><br>
>Sam<br>
<br>
I have seen Android and FreeBSD folks back porting specific commits.<br>
I think it might make their life easier if we update release notes separately.<br>
<br>
><br>
>> On 29 Apr 2020, at 2:05 pm, Robinson, Paul via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
>><br>
>> The way things work in practice is, when it’s time for a release, the release manager makes a general plea for people to write release notes.  This might include pleas to individuals whom the release manager has noticed made a note-worthy change; I seem to remember getting one such email once upon a time.<br>
>><br>
>> Asking for a release note as part of the review would be a new thing, but IMO brilliant.<br>
>> --paulr<br>
>> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>>> On Behalf Of James Henderson via llvm-dev<br>
>> Sent: Wednesday, April 29, 2020 8:58 AM<br>
>> To: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>><br>
>> Subject: [llvm-dev] What is the process for release notes for LLVM<br>
>><br>
>> Hi all,<br>
>><br>
>> I'm aware that LLVM has release notes, but I've never written one myself, despite making at times some fairly significant changes to the various llvm tools. Is there any documentation in LLVM on when a release note is appropriate and how to write one? Should reviewers be asking people to write release notes as part of reviews?<br>
>><br>
>> James<br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>