You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by GitBox <gi...@apache.org> on 2020/11/08 15:25:23 UTC

[GitHub] [commons-vfs] garydgregory commented on pull request #98: [VFS-778] Bug fixed: Returned channel will never be null

garydgregory commented on pull request #98:
URL: https://github.com/apache/commons-vfs/pull/98#issuecomment-723592562


   > hi @garydgregory I understand that i did not add any test cases. hence, it was not merged. But that was not the only issue. This was a critical bug and as a maintainer, i was expecting some agility from your part to address this issue. I also pointed out that existing code did not have any test case (which is not an excuse to not add new tc). Had you pointed out it earlier that it was mandatory, i would have written it. But you mentioned the same after you already merged someone else PR addressing the same issue.
   > 
   > Had i spent effort without digging it out that existing PR has resolved this issue already, it would have wasted my time. As a maintainer, i expect you to be aware of all the PRs you are merging so that duplicate PRs can be avoided.
   
   Hello @manishbansal8843 
   
   May I suggest that you adjust your expectations? I am a volunteer on this component as I am on all Apache projects I contribute to and as such provide my time for free and with my best intentions, always. I am not going to take the time to go and dissect what happened in what commit on what ticket and so on. Instead, I'll offer my support toward moving this issue forward. 
   
   I would not say a test is 'mandatory' in each and every case, but I my approach is to prioritize my attention to PRs that do have tests while those that don't go to the back of the queue. If a PR does not have a test, I just ask for one and move on. 
   
   Participating in the open source world for me, is not just creating PRs, throwing them over the wall, hoping that a project's maintainers match my expectations. For me, the process is a two way street, if I care enough about an issue, I create a PR, and manage my end of it, and try to participate in that project's process the best I can. Once you realize that there are folks on the other end that are just as busy as you are with day jobs, families, hobbies, and what nots, I think the process becomes less frustrating.
   
   Keeping it simple from my end, re-reading https://github.com/apache/commons-vfs/pull/98#issuecomment-719949458 and summarizing: For me, no test means an issue goes to the back of the queue, regressions should be avoided. I don't micro manage or provide micro feedback on the process, this is not a corporate job for me, quite the opposite indeed ;-)
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org