maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <>
Subject Re: number of bugs in maven-release-plugin
Date Sat, 27 Jun 2015 11:03:25 GMT
"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.


Op Sat, 27 Jun 2015 12:36:46 +0200 schreef Tibor Digana  

>>> 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:  
> Sent from the Maven Developers mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message