Phil, Is this somewhere codified? 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
