>> And without the ability to verify both the bug and the fix *I* won't apply those patches (unless the code clearly exposes the issue).
This is the problem. My colleague told me to have a look in ASF JIRA and see how many people provided patches. He said that he dislikes Maven community because of this reason they ignore their patches. So we should not be wondering that competitors are preferable because they can apply Groovy and patch directly in the script without asking us. Unless we understand this situation, the Maven will loose the reputation and most probably existing users. And back to your experiences with applying patches. I would at least try to install SCM, like Perforce server, and try to play with that. If not possible, I would make a branch and deploy the plugin as SNAPSHOT and let the person in Jira to retest it. The trick is that the status cannot be worse then it is now. Because if it is a good fix then our plugin has one bug less. If the fix is candidate to open another bug, then the number of bugs shortly decreased but is not worse than it was before. Example, what happened in surefire project. User reported bug in 2.18 with race condition in parallel tests. I could not reproduce the bug however understood the root cause. So we made an agreement that I will fix it in master and let the user test the SNAPSHOT version. He proved good fix. Otherwise I would revert the fix from HEAD. Sounds this works, hm? -- View this message in context: http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838719.html Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
