Perhaps we could improve this by: - Moving the release notes bit early in the release process
- Modifying the steps so the note is sent to marketing@ asking for people to "marketing-ify" the notes you got from CHANGES That can run in parallel with the binaries being prepared. If it happens it happens, if it doesn't it doesn't. But at least there's a clear call to action being made to the marketing team. (Does it make sense to cross-post the request to dev@ here also?) On 13 June 2014 15:35, Dirkjan Ochtman <[email protected]> wrote: > On Fri, Jun 13, 2014 at 3:17 PM, Noah Slater <[email protected]> wrote: >> Looping in Dirkjan as our active RM. >> >> Relevant part of our release procedure: >> >> http://wiki.apache.org/couchdb/Release_Procedure#Preparing_the_Release_Notes >> >> Template release notes: >> >> https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git;a=blob_plain;f=notes/template.html;hb=HEAD >> >> Relevant instruction from the release procedure: >> >> "Go through the CHANGES file and copy each section and summary." >> >> The RM should then send the following template email: >> >> https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git;a=blob_plain;f=email/request_notes.txt;hb=HEAD >> >> Looks like that wasn't sent for 1.6.0. > > Right. I kind of merged that into the SCHEDULE email, where I said: > >> I will use these release notes: >> >> http://www.apache.org/dist/couchdb/notes/1.6.0/ >> >> (Let me know if you have any suggestions for improvements.) > > Part of the problem with the current release procedure is that it is > not factored well enough into interrupts that drive the schedule. E.g. > the RM has to prepare candidate, then wait for the vote. After the > vote, call for binaries and wait for those. In this case, the section > of the procedure describing the release notes stuff comes after the > section describing how to prepare binaries (which I generally don't do > as an RM). So it's kind of easy to skip. > > Also, I believe in the past not many people wanted to have much to do > with crafting the release notes (most people IIRC wanted to generate > them automatically from commit messages). I think the current form is > a bit more friendly, so I spend time each release to go over each > commit in the release, pick out things that are slightly more > relevant/noticeable and describe them in a user-friendly way. I'm not > sure what you guys want to add beyond what we have now (or who is > going to spend time to add it), but I think a small prompt that the > release notes have been prepared should be enough to prompt it. > > Adding whatever needs adding to the relevant What's New documentation > chapter might be even better, and can be done at any time by anyone. > > Cheers, > > Dirkjan -- Noah Slater https://twitter.com/nslater
