<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 21, 2013 at 8:17 PM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</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"><br>
21 okt 2013 kl. 20:11 skrev "Asterisk Development Team" <<a href="mailto:asteriskteam@digium.com" target="_blank">asteriskteam@digium.com</a>>:<br>
<div><br>
> * --- Fix Not Storing Current Incoming Recv Address<br>
>  (Closes issue ASTERISK-22071. Reported by Alex Zarubin)<br>
><br>
> * --- Fix Segfault When Syntax Of A Line Under [applicationmap] Is<br>
>      Invalid<br>
>  (Closes issue ASTERISK-22416. Reported by <a href="http://CGI.NET" target="_blank">CGI.NET</a>)<br>
><br>
> * --- Tolerate presence of RFC2965 Cookie2 header by ignoring it<br>
>  (Closes issue ASTERISK-21789. Reported by Stuart Henderson)<br>
><br>
> * --- Fix Not Storing Current Incoming Recv Address<br>
>  (Closes issue ASTERISK-22071. Reported by Alex Zarubin)<br>
<br>
</div>Fixing the same issue twice is powerful :-)<br>
<br>
I would kindly like to suggest that we add the module name to these reports - which<br>
module was the recv address fixed in and where was the cookie2 header?<br></blockquote><div><br></div><div>Bah. I blame the person who chose those commits (/me looks around suspiciously)</div><div><br></div><div>
So I looked into this for a few minutes this morning. The script that generates the e-mail bombs is using pysvn (along with the digium_commits module in repotools) along with some JIRA integration to get the issue information. According to the docs for pysvn [1], the log messages returned from log() should contain a list of dictionaries containing information about the changed paths in subversion. Theoretically, we could parse that to find out what files were affected.</div>
<div><br></div><div>In practice, this attribute appears to be empty more often than not.</div><div><br></div><div style>The other option is we follow the convention that commit messages should, in their summary, list the affected modules. So the cookie summary should be:</div>
<div style><br></div><div style>http: Tolerate presence of RFC2965 Cookie2 header by ignoring it</div><div style><br></div><div style>Some folks do this all the time; some don't. It isn't part of the recommended commit message guidelines [2]. The downside of making it part of the commit message guidelines is that it eats into the 80 character limit for summaries and is (yet another) manual step.</div>
<div style><br></div><div style>I'll look into the PySVN returns some more to see if I can't figure out why we're not getting the changed paths on some of the commits - if I can make the change in the script, I will.</div>
<div style><br></div><div>[1] <a href="http://pysvn.tigris.org/docs/pysvn_prog_ref.html#pysvn_client">http://pysvn.tigris.org/docs/pysvn_prog_ref.html#pysvn_client</a></div><div><br></div><div>[2] <a href="https://wiki.asterisk.org/wiki/display/AST/Commit+Messages">https://wiki.asterisk.org/wiki/display/AST/Commit+Messages</a></div>
</div><div><br></div><div style>Matt</div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>