Greg Smith wrote: > On 06/24/2011 04:52 PM, Bruce Momjian wrote: > > That tagging is basically what I do on my first pass through the release > > notes. For the gory details: > > > > http://momjian.us/main/blogs/pgblog/2009.html#March_25_2009 > > > > Excellent summary of the process I was trying to suggest might be > improved; the two most relevant bits: > > 3 remove insignificant items 2.7k 1 day > 4 research and reword items 1k 5 days > > > Some sort of tagging to identify feature changes should drive down the > time spent on filtering insignificant items. And the person doing the > commit already has the context you are acquiring later as "research" > here. Would suggesting they try to write a short description at commit > time drive it and the "reword" phase time down significantly? Can't say > for sure, but I wanted to throw the idea out for > consideration--particularly since solving it well ends up making some of > this other derived data people would like to see a lot easier to > generate too.
Most of those five days is tracking down commits where I can't figure out the user-visible change, or if there is one, and wording things to be in a consistent voice. Git does allow me to look those up much faster than CVS. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers