On 3/26/14, 5:07 PM, Florian Pritz wrote:
Please try to keep subjects for git commits around the 50 char mark (or shorter). The threads subject would be fine.
Also try to add some explanatory text like why this change is needed and if applicable why it isn't done differently (in this case why you don't just increase the timeout) in the comment so this information isn't lost when someone steps through the git history in a couple of years. Believe it or not that will happen eventually and I'm always sad if I hit stuff with no comments.
And finally, if you use git-send-email you can put comments that aren't part of the patch, like the ones you have written above the patch thus far, after the 3 dashes down below.
I'm writing this mainly because I'm really used to the git way of things and I was rather confused when I read this thread.
Also one more thing: You might want to use -v2, -v3 and so on when sending patches via git-send-email. Those options will change the subject to [PATCH v2] and similar.
I will switch to git-send-email, and follow these guidelines; thanks for the suggestion.
You allow negative values here, but alpm_option_get_lowspeed*() use -1 to indicate an error. Setting the limit to -1 could result in wired stuff happening where the manpage would suggest that -1 simply results in download failures (which might be useful to someone who wants to test what happens in a dl failure case).
Either say negative values result in undefined behaviour (which it is given we rely on upstream and upstream doesn't specify it) or don't allow them at all which is probably the best.
Not allowing them at all seems like the most sane solution; I will revise the patch. Should the pacman.conf manual page explicitly disallow negative numbers? Thanks, Andrew