Release Notes: Volunteers needed

Has there been much thought of attempting to automate this process? I could imagine a fairly standard script that scrubbed a history for interesting tidbits. Of course a standard methodology for labeling types of commits would help this in the future.

A very simple script could at least do unique word counts and throw out words that match a dictionary (like parts of speech, contributer names, etc.). A more complex script could retain “links” back to the commits that contained certain words in case you wanted more information.

Has there been much thought of attempting to automate this process? I could imagine a fairly standard script that scrubbed a history for interesting tidbits. Of course a standard methodology for labeling types of commits would help this in the future.

A very simple script could at least do unique word counts and throw out words that match a dictionary (like parts of speech, contributer names, etc.). A more complex script could retain “links” back to the commits that contained certain words in case you wanted more information.

Hi Michael,

I don’t see any reasonable way that this can be automated. The script would either miss a bunch of really important things or get a ton of not very useful stuff. I’m open to suggestions of course and proof to the contrary though! :slight_smile:

-Chris

2011/10/28 Chris Lattner <clattner@apple.com>

Ok, sure, it would be reasonable to automate the next release or just have people update the 3.1 release notes when they make major changes. One issue is that the release notes are hacked on mainline for 3.0 now, so Dan Gohman can release note all the reaping he’s been doing, for example.

-Chris

2011/10/28 Chris Lattner <clattner@apple.com>

Has there been much thought of attempting to automate this process? I could imagine a fairly standard script that scrubbed a history for interesting tidbits. Of course a standard methodology for labeling types of commits would help this in the future.

A very simple script could at least do unique word counts and throw out words that match a dictionary (like parts of speech, contributer names, etc.). A more complex script could retain “links” back to the commits that contained certain words in case you wanted more information.

Hi Michael,

I don’t see any reasonable way that this can be automated. The script would either miss a bunch of really important things or get a ton of not very useful stuff. I’m open to suggestions of course and proof to the contrary though! :slight_smile:

-Chris

There is a way, but this method needs interaction of the deveoper. In mesa project, they add a line “Note: This is a candidate for 7.10 branch” to the commit message to automatically merge security fixes into older releases. In LLVM, it could be something like “ReleaseNote: New type system that adds more foo and removes some bar”. For the current bunch of changes you are right, you can’t automate this very good. And once the list of ReleaseNotes is extracted, a human can decide if these changes had really that fatal significance to appear in the release notes.

I don’t really see this as much different than someone remembering to update ReleaseNotes.html when they make changes worthy of being in the release notes. The root issue is that you still have to get people to do it and I just don’t see that really happening.

-Tanya

I’m willing to volunteer.

We’re looking to move our integration from LLVM 2.8 to 3.0, and so I’ll be doing some of this anyway.

Cheers,

Joe Abbey
Software Architect
Arxan Technologies, Inc.
1305 Cumberland Ave, Ste 215
West Lafayette, IN 47906
jabbey@arxan.com
www.arxan.com