<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 23, 2014 at 9:04 PM, David Thompson <span dir="ltr"><<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><snip><br>
- It would be nice to have tighter integration with the release process and issue tracking so that reports of features added and bugs fixed could be</blockquote><div><br></div><div>+1</div><div><br></div><div>The bugtracker is only loosely integrated into the process. I'ld like it to be tighter too so that hopefully the number of bugs in the tracker will be limited and always recent.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> generated. I think what we do of that is mostly by hand now, isn't it?<br>


<br></blockquote><div><br></div><div>Yes mostly by hand.</div><div><br></div><div>* before a release we scan the bug tracker and try to address the most important reports.</div><div><br></div><div>* during the release candidate cycle I use the bug tracker and the "found in" "fixed in" fields to keep track of the bugs that need to be fixed before the final release</div>

<div><br></div><div>We keep track of what changed in the release entirely outside of the bug tracker.</div><div><br></div><div>* I send an email to all authors and ask them to summarize their changes  to make up the release notes so we know overall what happened.</div>

<div><br></div><div>* Then I run $VTKSRC//Utilities/Maintenance/sematicDiffVersion.py to make the API diff report so that we have a list of the added / newly legacy'd /  and removed items.</div><div>See: <a href="http://www.vtk.org/Wiki/VTK/API_Changes_6_0_0_to_6_1_0">http://www.vtk.org/Wiki/VTK/API_Changes_6_0_0_to_6_1_0</a></div>

<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Suggested Requirements:-)<br>
<br>
- Review system comments should be Markdown or rST or something easily presented as HTML which can include links -- at least to the VTK wiki and bug tracker, if nothing else. It would be really nice if pull requests could effectively become parts of a wiki page or blog so that we could curate user-guide-style documentation instead of just doxygen reference docs. Not that every topic would have to become part of a user's guide, but it should be easy to pull topic info into a user's guide.<br>


<br>
- An anti-requirement: Less e-mail spam when (1) a topic includes multiple commits and/or (2) automated testing completes. For instance, I can think of one topic I'm a reviewer on that has 40-something commits. There are 16 changesets and reviewers get 1 per commit per changeset-the-commit-is-modified.<br>


<br>
        2¢,<br>
        David<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
</blockquote></div><br></div></div>