On 9/24/15 9:50 AM, Bernd wrote: > Phil, Is this somewhere codified? As I said at the end, I don't think this needs to be codified. The only actual requirement is CLA / software grant coverage for large contributions. We have agreed several times (should be in the list archives) not to standardize commit message formats / templates. I rant now and then about the content of them, which I think is the important part, but even there I don't think that "rules" are the answer. That a commit comes from a contributed patch can be useful information, so I include it. No need to over-standardize. I just responded with how I do it.
Phil > > 2015-09-24 18:47 GMT+02:00 Phil Steitz <phil.ste...@gmail.com>: >> On 9/24/15 8:59 AM, Bernd wrote: >>> Hello, >>> >>> do we have this rule to include the name of a patch contributor into >>> the commit message? I havent seen that beeing used so far in >>> commons-vfs, and the commit does contain Antonio's name in the >>> changes.xml due-to= credits. I think a while back we had the >>> discussion that not even this is required for smaller contributions. >>> (but I try to do it for VFS on all changes). >> I try to do this (though I sometimes forget and have to go back and >> fix things later): >> >> Always mention contributor in the commit (basically tells where the >> code came from, no attribution means I did it myself). >> Always include due-to in changes.xml. >> Add contributor to contributors section of the pom if the >> contribution is significant. >> >> Very small changes may not be represented in changes.xml, but are >> still attributed in the commit message. To me, the commit message >> describes the commit; the changes.xml and contributors references >> acknowledge the contribution. >> >> Different components do this differently. I don't think we have or >> need to have rigid rules, other than that really large contributions >> should be granted under CLA. >> >> Phil >>> Gruss >>> Bernd >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Antonio Petrelli (JIRA) <j...@apache.org> >>> Date: 2015-09-24 10:50 GMT+02:00 >>> Subject: [jira] [Commented] (VFS-567) Timeout in vsFTPd causes >>> exception when executing another command >>> To: iss...@commons.apache.org >>> >>> >>> >>> [ >>> https://issues.apache.org/jira/browse/VFS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14906040#comment-14906040 >>> ] >>> >>> Antonio Petrelli commented on VFS-567: >>> -------------------------------------- >>> >>> Thanks Bernd, however, as I am an emeritus PMC member of other Apache >>> project, I remember that the name of the contributor should be >>> inserted in the commit log. >>> >>>> Timeout in vsFTPd causes exception when executing another command >>>> ----------------------------------------------------------------- >>>> >>>> Key: VFS-567 >>>> URL: https://issues.apache.org/jira/browse/VFS-567 >>>> Project: Commons VFS >>>> Issue Type: Bug >>>> Affects Versions: 2.1 >>>> Environment: vsFTPd 3.0.2 on Kubuntu 14.10 >>>> Reporter: Antonio Petrelli >>>> Assignee: Bernd Eckenfels >>>> Fix For: 2.1 >>>> >>>> Attachments: commons-vfs-disconnect.diff, vfs-quit-problem.zip >>>> >>>> >>>> After a timeout in vsFTPd, a QUIT command is sent and a 421 Timeout >>>> response is sent back to the Java client. After that, a SocketException >>>> (broken pipe) is raised and not correctly managed. >>>> I am attaching a test case, this is the stack trace: >>>> Exception in thread "main" org.apache.commons.vfs2.FileSystemException: >>>> Could not determine the type of file "ftps://localhost/javadev/vfs/input". >>>> at >>>> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:1526) >>>> at QuitProblemMain.main(QuitProblemMain.java:41) >>>> Caused by: java.net.SocketException: Pipe interrotta >>>> at java.net.SocketOutputStream.socketWrite0(Native Method) >>>> at >>>> java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) >>>> at java.net.SocketOutputStream.write(SocketOutputStream.java:153) >>>> at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431) >>>> at sun.security.ssl.OutputRecord.write(OutputRecord.java:417) >>>> at >>>> sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:864) >>>> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:835) >>>> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123) >>>> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) >>>> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) >>>> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) >>>> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) >>>> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) >>>> at java.io.BufferedWriter.flush(BufferedWriter.java:254) >>>> at org.apache.commons.net.ftp.FTP.__send(FTP.java:505) >>>> at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:479) >>>> at >>>> org.apache.commons.net.ftp.FTPSClient.sendCommand(FTPSClient.java:541) >>>> at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:608) >>>> at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:582) >>>> at org.apache.commons.net.ftp.FTP.quit(FTP.java:864) >>>> at >>>> org.apache.commons.vfs2.provider.ftp.FTPClientWrapper.disconnect(FTPClientWrapper.java:118) >>>> at >>>> org.apache.commons.vfs2.provider.ftp.FTPClientWrapper.listFiles(FTPClientWrapper.java:152) >>>> at >>>> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetChildren(FtpFileObject.java:136) >>>> at >>>> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildFile(FtpFileObject.java:106) >>>> at >>>> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:192) >>>> at >>>> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:320) >>>> at >>>> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:1517) >>>> ... 1 more >>> >>> -- >>> This message was sent by Atlassian JIRA >>> (v6.3.4#6332) >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
