On Wed, Jun 15, 2011 at 1:02 AM, Cor Nouws <span dir="ltr"><<a href="mailto:oolst@nouenoff.nl">oolst@nouenoff.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi John, </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> ...</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
...<br>
What I am more looking for, is sometimes the hints related to (some of) the vast amount of code clean-ups/improvements, that possibly have influence on area A or B. (In the commit-logs for master)<br>
<br> Maybe maybe it is possible for the involved devs, when they think it is possibly relevant, to add a few words to the description so that it is indeed able to read that in the summaries.<br>
<br> ...
<br> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Sounds reasonable?<br></blockquote><div><br></div><div>It is quite reasonable to try to get the dev work result to mesh with qa testing. Sadly, git requests that the short commit message be <41 characters. Personally, I struggle with that at each commit ;-)... Git does allow more lines in the commit header but those usually describe changes to the code, are often technical and some of the comments about the removed/replaced code do *not* belong on the wiki. </div>
<div><br></div><div>In the wiki of the future, the summary pages' bug numbers will link to the actual bug reports (at least for fdo) so that the summary indirectly provides the intended functional changes in LibreOffice. The bug reports often contain steps to reproduce the bug that make it clear where to test the fix. Perhaps the bug-fix section of the summary could eventually include the bug summary (short desc) next to the link as well.</div>
<div><br></div><div>The addition of a bug number to the short commit message is the most efficient way for the developers to pass testing info to qa. </div><div><br></div><div>Thanks for raising and clarifying the issue of qa's need for clues about how to find and test the latest changes in any of master, 3.4 or the release branches, </div>
<div><br></div>LeMoyne<br>