On 06/24/2011 04:52 PM, Bruce Momjian wrote: <blockquote cite="mid:201106242052.p5OKqj319301@momjian.us"
type="cite">Thattagging is basically what I do on my first pass through the release<br /><pre wrap="">notes. For the
gorydetails:
<a class="moz-txt-link-freetext"
href="http://momjian.us/main/blogs/pgblog/2009.html#March_25_2009">http://momjian.us/main/blogs/pgblog/2009.html#March_25_2009</a>
</pre></blockquote><br/> Excellent summary of the process I was trying to suggest might be improved; the two most
relevantbits:<br /><br /><table border="1" summary=""><tbody><tr><td>3</td><td>remove insignificant
items</td><td>2.7k</td><td>1day</td></tr><tr><td>4</td><td>research and reword items</td><td>1k</td><td>5
days</td></tr></tbody></table><br/> Some sort of tagging to identify feature changes should drive down the time spent
onfiltering 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
timedown significantly? Can't say for sure, but I wanted to throw the idea out for consideration--particularly since
solvingit well ends up making some of this other derived data people would like to see a lot easier to generate too.<br
/><br/><pre class="moz-signature" cols="72">--
Greg Smith 2ndQuadrant US <a class="moz-txt-link-abbreviated"
href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support <a class="moz-txt-link-abbreviated"
href="http://www.2ndQuadrant.us">www.2ndQuadrant.us</a>
</pre>
