"The trick is that the status cannot be worse then it is now."
Sadly that's not always true.
A good example are the GIT fixes in SCM, which should make it more robust,
but in the end did more harm than good, even with unittest included. For
the reporter it seemed to work, but not for the whole world anymore. And
again gave the plugin a less positive reputation (for some it was another
reason to confirm that you shouldn't use this plugin), even though it was
another project causing the issues. So I really would like a teammember
knowing the system to verify and commit it. And the team should be big
enough to cover them all. Otherwise we should just look for them.
Quite often it is not the maven-release-plugin itself which is the issue.
And there are cases where people are trying to create backdoors which I
just simply refuse. In such cases you need to start the discussion why
they need it and that often exposes a valid root cause.
Do you (or your colleague) have a number of issues you'd like to see fixed?
Personally I don't mind having a a lot of issues os long as they all add
something. Once somebody (who?) has the need to work on this plugin he can
just continue on the open issues.
AFAIK there are no real blocking issues so I chose to work on other stuff
right now. If it is a real issue, they know how to find us, Fred did it a
couple of times :) Then we can work together on such issue, that works
often better and is much more fun.
Robert
Op Sat, 27 Jun 2015 12:36:46 +0200 schreef Tibor Digana
<[email protected]>:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
