You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Tibor Digana <ti...@apache.org> on 2015/06/26 22:55:02 UTC
number of bugs in maven-release-plugin
Do you know what's wrong with Jira on maven-release-plugin MRELEASE?
It's growing nearly to 200 open bugs. It looks like the community use to
fix 5 in each release. Maybe the community should start closing irrelevant
bugs which better helps concentrating on more relevant bugs.
We started this strategy in surefire plugin and closed irrelevant bugs.
This iteration has happened several times already. Then we released cca 30
fixed issues in every major release. This way we are now under 100 open
issues and still cutting the bugs down.
I have a strategy to handle new bug as it comes in Jira and ask the
originator to fix it and offering some hints to him/her. This way we have
got few more contributors in surefire project. Even if the contributor does
not implement properly, it always saves my time and I can still modify his
implementation or ask him to reimplement it.
Maybe it's the only question if we really want to have better statistics
and fix more bugs.
Maybe it's a question of resources like number of committers. We have some
contributors on GitHub, so maybe it is as simple as to ask them get this
position.
Cheers
Re: number of bugs in maven-release-plugin
Posted by Robert Scholte <rf...@apache.org>.
Exactly my plan
Op Sat, 27 Jun 2015 12:56:43 +0200 schreef Tibor Digana
<ti...@apache.org>:
> @rfscholte
> If the plugin needs redesign, I guess M3 is the rightest milestone for
> that.
> Everybody should accept that major version comes with breaking something
> but
> fixing a lot as well.
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838731.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: number of bugs in maven-release-plugin
Posted by Tibor Digana <ti...@apache.org>.
@rfscholte
If the plugin needs redesign, I guess M3 is the rightest milestone for that.
Everybody should accept that major version comes with breaking something but
fixing a lot as well.
--
View this message in context: http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838731.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: number of bugs in maven-release-plugin
Posted by Tibor Digana <ti...@apache.org>.
>> At least, without breaking stuff for existing users.
This has solution as well. Just accept the patch in a release with new
incremental version and release the plugin very often. You can always easily
ask in Jira to retest with a bunch of versions and identify where it started
not working and you know that the big fix has a side effect.
--
View this message in context: http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838723.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: number of bugs in maven-release-plugin
Posted by Fred Cooke <fr...@gmail.com>.
Some of the issues are mine. I'm pretty sure that at some point I realised
that to get it working properly for my use case would require forking it to
a privately released version. I guess now that it's mostly or all in git,
that's feasible. The conflicting requirements across SCMs, the highly
varied usage, and the historical bias towards SVN that runs deep through
far more than just m-rel-p make it pretty difficult, though. At least,
without breaking stuff for existing users.
I'm curious as to what an "irrelevant bug" is? If it's not a bug, then
close on review immediately after creation.
Fred.
On Sat, Jun 27, 2015 at 9:57 PM, Robert Scholte <rf...@apache.org>
wrote:
> It was even worse.
> When I joined this team I started working on this plugin and managed to
> close half of them ( let's say from 300 back to 150 issues).
> Right now there's a situation where new issues are often easy to reproduce.
> The older ones are often harder to reproduce or are already fixed.
> I've already asked for feedback for a lot of issues. If I go through that
> list again,I'm pretty sure I can close a lot again.
> Then there are some issues which require some redesign, but without good
> code coverage it is hard to discover regression.
> For instance, I'd like to replace jdom with woodstox, because there are a
> lot of hacks in the code to please jdom.
> When I'm done with the M3 plugin migration I'd love to pick it up again.
>
> Then there's this tricky thing that it should work for all SCM's. It's
> great that maven-scm is a separate project, but that might need even more
> attention. But then we hit the problem that there's not enough knowledge
> for all these systems. 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).
>
> thanks,
> Robert
>
>
> Op Fri, 26 Jun 2015 22:55:02 +0200 schreef Tibor Digana <
> tibordigana@apache.org>:
>
>
> Do you know what's wrong with Jira on maven-release-plugin MRELEASE?
>> It's growing nearly to 200 open bugs. It looks like the community use to
>> fix 5 in each release. Maybe the community should start closing irrelevant
>> bugs which better helps concentrating on more relevant bugs.
>>
>> We started this strategy in surefire plugin and closed irrelevant bugs.
>> This iteration has happened several times already. Then we released cca 30
>> fixed issues in every major release. This way we are now under 100 open
>> issues and still cutting the bugs down.
>> I have a strategy to handle new bug as it comes in Jira and ask the
>> originator to fix it and offering some hints to him/her. This way we have
>> got few more contributors in surefire project. Even if the contributor
>> does
>> not implement properly, it always saves my time and I can still modify his
>> implementation or ask him to reimplement it.
>>
>> Maybe it's the only question if we really want to have better statistics
>> and fix more bugs.
>> Maybe it's a question of resources like number of committers. We have some
>> contributors on GitHub, so maybe it is as simple as to ask them get this
>> position.
>>
>> Cheers
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: number of bugs in maven-release-plugin
Posted by Benson Margulies <bi...@gmail.com>.
On Sat, Jun 27, 2015 at 5:34 PM, Fred Cooke <fr...@gmail.com> wrote:
> Benson, I'm curious as to what you did, and also how it broke both for Git
> users and other users. Any links/refs/bugs/emails/etc to read?
It's been a while, but here's the narrative as I recall it.
(background: before 2.5, the m-r-p completely broke for git, and it
took some fixing. I don't think I was involved.)
Several people reported that you couldn't make the m-r-p work when the
maven project you were releasing was not at the root of the repo. This
was/is a documented feature, facilitated by a specific parameter in
the pom, that informs the release plugin of the relative location of
the pom in the project. (You might ask yourself: why can't the plugin
figure this out for itself?)
I tracked down an explanation for this with the version of git I was
using, and I made a fix. As I recall, the git people had changed the
format of some information produced in supposed porcelain mode (which
is supposed to produce a robust API.) Or, maybe the m-r-p wasn't
properly using porcelain. I can't recall. Anyhow, I added an
integration test (a task made truly awful by the fact that the plugins
are trapped supporting Maven 2, and the test support classes for this
sort of thing in Maven 2 are poorly documented and understood), it
passed, I committed, we released.
And promptly, some people reported some combination of 'the fix
doesn't fix for me' and perhaps also 'it used to work for me and now
it does not.'
I don't think that I _ever_ got it to work for all the users who complained.
>
> Was it just a case of leveraging features only available in very new
> versions? A data point if so:
>
> This sid laptop 2.1.3
> My wheezy server 1.7.10.4
> Work ucuntu 14.10 box 2.1.0
> Current win git default 1.9.5
>
> However I believe I've been using it since 1.5 or 1.6 or maybe earlier and
> the core functionality is virtually unchanged since then, no? I remember
> the porcelain stuff changing, so perhaps it was this?
>
> egit/jgit has some serious flaws that render certain projects unusable with
> it (Java limitation on symlinks)
>
> It also seems/seemed to completely ignore ~/.ssh/config and other similar
> things. I forget the details as I'm pretty sure I use real git in my parent
> pom setup.
>
> Regards,
>
> Fred.
>
> On Sun, Jun 28, 2015 at 5:01 AM, Benson Margulies <bi...@gmail.com>
> wrote:
>
>> Tibor,
>>
>> Well, we'll see. Let's parse this situation into some smaller ones. We
>> don't need any votes. We need initiative coupled with enough time,
>> knowledge, and energy to make progress.
>>
>> There's the maven core and the pom. Quite a while ago, I tried to push
>> this; but I don't have the necessary intellectual investment in the maven
>> core to lead here. The community needn't / shouldn't wait for Jason, but
>> the problem of 'we can't change the pom, all those other tools will bust'
>> is a hard problem.
>>
>> Then we have plugins. In my entirely personal opinion, there are too many
>> plugins inside the Apache Maven project. We would be more successful, I
>> submit, if the formal project owned a very minimal set of completely
>> essential plugins, and the others were maintained by communities of the
>> interested. Does the release plugin belong inside or outside?
>>
>> From a functional standpoint, I prefer the gitflow maven plugin to the
>> maven-release-plugin. Sadly, the gitflow plugin is much too buggy for
>> production use. It does actual merges, and sometimes they fail and leave a
>> less. So I try to fix problems in the release plugin when they bite me.
>>
>> Right now, the release plugin rides on top of the SCM plugin. The SCM
>> plugin tries to be completely general. The release plugin has very specific
>> needs: update versions in poms, check them in, create tags, check out at
>> tags. Maybe we'd have a happier release plugin if it had a tailored
>> abstraction. Maybe not.
>>
>> --benson
>>
>>
>>
>>
>>
>>
>> On Sat, Jun 27, 2015 at 10:14 AM, Tibor Digana <ti...@apache.org>
>> wrote:
>>
>> > @Benson
>> >
>> > Excellent!
>> >
>> > Since you have good inside of this problem you should post a Vote with
>> this
>> > list of activities and I hope that others will extend it.
>> >
>> > As you and Robert Scholte described, the situation around
>> > maven-release-plugin and SCM artifacts is pathetic. I hope Jason will
>> bring
>> > some inspiration to make us all more optimistic.
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> >
>> http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838800.html
>> > Sent from the Maven Developers mailing list archive at Nabble.com.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: number of bugs in maven-release-plugin
Posted by Fred Cooke <fr...@gmail.com>.
Benson, I'm curious as to what you did, and also how it broke both for Git
users and other users. Any links/refs/bugs/emails/etc to read?
Was it just a case of leveraging features only available in very new
versions? A data point if so:
This sid laptop 2.1.3
My wheezy server 1.7.10.4
Work ucuntu 14.10 box 2.1.0
Current win git default 1.9.5
However I believe I've been using it since 1.5 or 1.6 or maybe earlier and
the core functionality is virtually unchanged since then, no? I remember
the porcelain stuff changing, so perhaps it was this?
egit/jgit has some serious flaws that render certain projects unusable with
it (Java limitation on symlinks)
It also seems/seemed to completely ignore ~/.ssh/config and other similar
things. I forget the details as I'm pretty sure I use real git in my parent
pom setup.
Regards,
Fred.
On Sun, Jun 28, 2015 at 5:01 AM, Benson Margulies <bi...@gmail.com>
wrote:
> Tibor,
>
> Well, we'll see. Let's parse this situation into some smaller ones. We
> don't need any votes. We need initiative coupled with enough time,
> knowledge, and energy to make progress.
>
> There's the maven core and the pom. Quite a while ago, I tried to push
> this; but I don't have the necessary intellectual investment in the maven
> core to lead here. The community needn't / shouldn't wait for Jason, but
> the problem of 'we can't change the pom, all those other tools will bust'
> is a hard problem.
>
> Then we have plugins. In my entirely personal opinion, there are too many
> plugins inside the Apache Maven project. We would be more successful, I
> submit, if the formal project owned a very minimal set of completely
> essential plugins, and the others were maintained by communities of the
> interested. Does the release plugin belong inside or outside?
>
> From a functional standpoint, I prefer the gitflow maven plugin to the
> maven-release-plugin. Sadly, the gitflow plugin is much too buggy for
> production use. It does actual merges, and sometimes they fail and leave a
> less. So I try to fix problems in the release plugin when they bite me.
>
> Right now, the release plugin rides on top of the SCM plugin. The SCM
> plugin tries to be completely general. The release plugin has very specific
> needs: update versions in poms, check them in, create tags, check out at
> tags. Maybe we'd have a happier release plugin if it had a tailored
> abstraction. Maybe not.
>
> --benson
>
>
>
>
>
>
> On Sat, Jun 27, 2015 at 10:14 AM, Tibor Digana <ti...@apache.org>
> wrote:
>
> > @Benson
> >
> > Excellent!
> >
> > Since you have good inside of this problem you should post a Vote with
> this
> > list of activities and I hope that others will extend it.
> >
> > As you and Robert Scholte described, the situation around
> > maven-release-plugin and SCM artifacts is pathetic. I hope Jason will
> bring
> > some inspiration to make us all more optimistic.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838800.html
> > Sent from the Maven Developers mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: number of bugs in maven-release-plugin
Posted by Benson Margulies <bi...@gmail.com>.
Tibor,
Well, we'll see. Let's parse this situation into some smaller ones. We
don't need any votes. We need initiative coupled with enough time,
knowledge, and energy to make progress.
There's the maven core and the pom. Quite a while ago, I tried to push
this; but I don't have the necessary intellectual investment in the maven
core to lead here. The community needn't / shouldn't wait for Jason, but
the problem of 'we can't change the pom, all those other tools will bust'
is a hard problem.
Then we have plugins. In my entirely personal opinion, there are too many
plugins inside the Apache Maven project. We would be more successful, I
submit, if the formal project owned a very minimal set of completely
essential plugins, and the others were maintained by communities of the
interested. Does the release plugin belong inside or outside?
>From a functional standpoint, I prefer the gitflow maven plugin to the
maven-release-plugin. Sadly, the gitflow plugin is much too buggy for
production use. It does actual merges, and sometimes they fail and leave a
less. So I try to fix problems in the release plugin when they bite me.
Right now, the release plugin rides on top of the SCM plugin. The SCM
plugin tries to be completely general. The release plugin has very specific
needs: update versions in poms, check them in, create tags, check out at
tags. Maybe we'd have a happier release plugin if it had a tailored
abstraction. Maybe not.
--benson
On Sat, Jun 27, 2015 at 10:14 AM, Tibor Digana <ti...@apache.org>
wrote:
> @Benson
>
> Excellent!
>
> Since you have good inside of this problem you should post a Vote with this
> list of activities and I hope that others will extend it.
>
> As you and Robert Scholte described, the situation around
> maven-release-plugin and SCM artifacts is pathetic. I hope Jason will bring
> some inspiration to make us all more optimistic.
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838800.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: number of bugs in maven-release-plugin
Posted by Tibor Digana <ti...@apache.org>.
@Benson
Excellent!
Since you have good inside of this problem you should post a Vote with this
list of activities and I hope that others will extend it.
As you and Robert Scholte described, the situation around
maven-release-plugin and SCM artifacts is pathetic. I hope Jason will bring
some inspiration to make us all more optimistic.
--
View this message in context: http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838800.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: number of bugs in maven-release-plugin
Posted by Benson Margulies <bi...@gmail.com>.
To begin with, we have a lot more plugins than we have people to work on them.
Then, we have some critical functionality that is very fragile.
Perhaps this is because the problem is fundamentally hard. Perhaps it
is because the abstraction is fundamentally wrong.
In the case of git, where I think that I'm (one of) the perp(s) being
referred to, I tried to satisfy a set of very unhappy users. The
difficulty is that Maven SCM does not interact with git through a
clean abstraction. So my attempt to fix a problem that afflicted a set
of users (admittedly including myself) with one version of git in one
usage pattern, caused problems with other users with other versions of
git. All the tests we had passed with the environment available to me
and the CI system we have. So we're about at the point where it's
nearly impossible to change anything interesting.
To avoid complete constipation here, I can imagine:
1: there is a new git SCM artifact (or branch) for each materially
different version of git, so that a person with access to and interest
in version X can fix things without being prepared to set up and test
versions Y, Z, etc.
2: there is a testing apparatus that we maintain that can regress all
this against a wide spectrum. This might not be good enough -- if the
requirement to commit a patch to the code was to succeed in fighting
through all the problems that manifest in all the versions, I might
never have enough time to do anything.
3: analysis would lead to a different way to think about the
abstraction of working with git so that we could have a less fragile
result.
4: cooperation with someone on the git / egit side of the house would
lead to an API we could talk to that would avoid some of this trouble.
Some of this is amplified by the problem that there isn't enough
information in the POM data model to handle the requirements of the
SCM's very well, and we've ground to a halt in advancing to a next POM
data model.
On Sat, Jun 27, 2015 at 7:10 AM, Tibor Digana <ti...@apache.org> wrote:
>>> And the team should be big enough to cover them all. Otherwise we should
> just look for them.
>
> Agree. So why not to introduce more committers.
> This still sounds to me like we do not have environment to cover the fix in
> tests on all SCM we support.
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838743.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: number of bugs in maven-release-plugin
Posted by Tibor Digana <ti...@apache.org>.
>> And the team should be big enough to cover them all. Otherwise we should
just look for them.
Agree. So why not to introduce more committers.
This still sounds to me like we do not have environment to cover the fix in
tests on all SCM we support.
--
View this message in context: http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838743.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: number of bugs in maven-release-plugin
Posted by Robert Scholte <rf...@apache.org>.
"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
<ti...@apache.org>:
>>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: User Community was (Re: number of bugs in maven-release-plugin)
Posted by Andreas Gudian <an...@gmail.com>.
2015-06-27 14:40 GMT+02:00 robert.patrick@oracle.com <
robert.patrick@oracle.com>:
>
> The second time, I tried to interact around someone else's problem with
> mvnDebug.cmd. No one ever responded.
>
That's not really true - people did respond, it's just that no one stood up
and put your suggestion into committable code.
As with many projects that have such a long history and a large number of
users, it is sometimes difficult to be heard. Look at Eclipse, Hibernate
ORM, Glassfish or the JDK itself. If you want something to be done, you
have to make sure that you make it as easy as possible for the committers
to review and apply the patch. And maybe make yourself heard if still no
one reacted... We all do things here in our free time for fun and sometimes
other stuff is more fun at a given time... ;-)
Anyway, someone else had opened a PR at github for that mvnDebug issue and
Jason had already created a corresponding Jira ticket for it... But nothing
really happened, yet.
You bringing that up now made me take a look and I'll fix it, basically the
way you suggested it, as it fit's what's done in the .cmd script.
So thanks for the heads-up!
Andreas
Re: User Community was (Re: number of bugs in maven-release-plugin)
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Robert,
On 6/27/15 2:40 PM, robert.patrick@oracle.com wrote:
> I have only tried to interact a few times myself (others in my team have tried as well).
> The first time, my team and I get a patch we submitted
>to enhance the wagon-http for SSO-protected repositories adopted
thanks to Olivier Lamy.
>
Successful...done.
> The second time, I tried to interact around someone else's problem with mvnDebug.cmd. No one ever responded.
Ok...Nr. 1.
>
> My current problem, that I posted to the new versions plugin Google group yesterday,
> is one that someone from JBoss posted about a year ago
> but seems to have never been addressed.
> That is, being able to update dependency versions where the scope
> is set to import using the use-latest-releases goal.
> You can sort of workaround it using update-properties but that
> goal lacks the ability to constrain the segment of the
> version number that gets updated. (i.e., use-latest-releases
> goal's allowMajorUpdates, allowMinorUpdates, allowIncrementalUpdates).
This is MojoHaus versions maven plugin and i saw it.....
>
> My team created a number of custom plugins where we
> used code and modified it for our purposes to
> function like we wanted.
Ok...
Had there be any suggestions to the original plugins (JIRA issues etc)
to improve the funcitonality according to what you or you team members
suggested ?
> I don't think enumerating those are particularly important...
That's weird, cause you don't think it's important.
Hm..I have explicitly asked for exactly that kind of information...
But this is the point. So how could i do anything if i don't have any
kind of information which i explictly asked for?
>
> I don't want to cause trouble or get into some huge debate.
You don't cause trouble...a discussion might make sense...debate is an
other story...
I am giving you my perception. You can choose to take it as feedback
or not, that is your choice.
>
> Robert Patrick <ro...@oracle.com>
> VP, Oracle Corporation
> Mobile: +1.469.556.9450
> Sent from my iDevice
>
>> On Jun 27, 2015, at 6:36 PM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
>>
>> Hi Robert,
>>
>>
>>> On 6/27/15 12:51 PM, robert.patrick@oracle.com wrote:
>>> Sorry for butting in but as someone who is a staunch supporter of
>>> Maven within my company and its user community,
>>> I have to agree that the difficulty in engaging
>>> the Maven developers to even discuss issues
>>> is too high.
>>
>> First i would be interested in examples of this kind, cause
>> unfortunately i have to say i never saw your name on the dev/users list...nor can i remember about your name in jira issue (I have admit that i'm not that long part of the Maven team but i'm reading the list a longer time)..may be just i oversight or mistaken something....
>>
>>> I often find myself fixing plugins by forking
>>> my own private versions since doing
>>> anything else is too slow/painful.
>>
>> Can you give some examples (or a list of them) of those fixes and for which plugins you have to do so? And how often in number is ?
>>
>>>
>>> Sorry for the intrusion...
>>
>> No excuse needed and that's no intrusion.......
>>
>> It is very important that someone raises his hand that there is something which need to pay attention to....
>>
>>>
>>> Robert Patrick <ro...@oracle.com>
>>> VP, Oracle Corporation
>>> Mobile: +1.469.556.9450
>>> Sent from my iDevice
>>>
>>> On Jun 27, 2015, at 5:36 PM, Tibor Digana <ti...@apache.org> wrote:
>>>
>>>>>> 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.
>>
>> The problem of many patches is simply they lack of tests, i often write to them they should produce tests...but i often get the feedback: I don't have time to write test just fix it...or i don't get any feedback at all...
>>
>> Furthermore as Robert Scholte mentioned people often see only their limited scope which often conflicts with the whole idea's, concept of Maven / Plugins in general...which results in not acceptiong 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.
>>
>> Which would exactly results in coded builds which is in the end much more complicated and worse maintainable than any Maven build every be....
>>
>>
>>> 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?
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: User Community was (Re: number of bugs in maven-release-plugin)
Posted by "robert.patrick@oracle.com" <ro...@oracle.com>.
I have only tried to interact a few times myself (others in my team have tried as well). The first time, my team and I get a patch we submitted to enhance the wagon-http for SSO-protected repositories adopted thanks to Olivier Lamy.
The second time, I tried to interact around someone else's problem with mvnDebug.cmd. No one ever responded.
My current problem, that I posted to the new versions plugin Google group yesterday, is one that someone from JBoss posted about a year ago but seems to have never been addressed. That is, being able to update dependency versions where the scope is set to import using the use-latest-releases goal. You can sort of workaround it using update-properties but that goal lacks the ability to constrain the segment of the version number that gets updated. (i.e., use-latest-releases goal's allowMajorUpdates, allowMinorUpdates, allowIncrementalUpdates).
My team created a number of custom plugins where we used code and modified it for our purposes to function like we wanted. I don't think enumerating those are particularly important...
I don't want to cause trouble or get into some huge debate. I am giving you my perception. You can choose to take it as feedback or not, that is your choice.
Robert Patrick <ro...@oracle.com>
VP, Oracle Corporation
Mobile: +1.469.556.9450
Sent from my iDevice
> On Jun 27, 2015, at 6:36 PM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
>
> Hi Robert,
>
>
>> On 6/27/15 12:51 PM, robert.patrick@oracle.com wrote:
>> Sorry for butting in but as someone who is a staunch supporter of
> > Maven within my company and its user community,
> > I have to agree that the difficulty in engaging
> > the Maven developers to even discuss issues
> > is too high.
>
> First i would be interested in examples of this kind, cause
> unfortunately i have to say i never saw your name on the dev/users list...nor can i remember about your name in jira issue (I have admit that i'm not that long part of the Maven team but i'm reading the list a longer time)..may be just i oversight or mistaken something....
>
> > I often find myself fixing plugins by forking
> > my own private versions since doing
> > anything else is too slow/painful.
>
> Can you give some examples (or a list of them) of those fixes and for which plugins you have to do so? And how often in number is ?
>
>>
>> Sorry for the intrusion...
>
> No excuse needed and that's no intrusion.......
>
> It is very important that someone raises his hand that there is something which need to pay attention to....
>
>>
>> Robert Patrick <ro...@oracle.com>
>> VP, Oracle Corporation
>> Mobile: +1.469.556.9450
>> Sent from my iDevice
>>
>> On Jun 27, 2015, at 5:36 PM, Tibor Digana <ti...@apache.org> wrote:
>>
>>>>> 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.
>
> The problem of many patches is simply they lack of tests, i often write to them they should produce tests...but i often get the feedback: I don't have time to write test just fix it...or i don't get any feedback at all...
>
> Furthermore as Robert Scholte mentioned people often see only their limited scope which often conflicts with the whole idea's, concept of Maven / Plugins in general...which results in not acceptiong 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.
>
> Which would exactly results in coded builds which is in the end much more complicated and worse maintainable than any Maven build every be....
>
>
> > 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?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: User Community was (Re: number of bugs in maven-release-plugin)
Posted by Tibor Digana <ti...@apache.org>.
>> Which would exactly results in coded builds which is in the end much
>> more complicated and worse maintainable than any Maven build every be....
I agreed that the build is worse maintainable after long time, but the
problem is that Java Hamcrest project, as an example, decided to use Graddle
even after my pressure to accept Maven. They decided because of the only one
reason : It's younger. They did not say Maven has a bug. Their decision was
not professional and most probably such builds like they have would not be
portable in another SCM or platform or CI but they do not know it now yet.
People want to always try to use something new but there is also personal
attitude, like it was with Java security and broken RSA 1. A lot of devs
hate Java but they like JVM. Another problem why they hate Java was the
problem with JRE stability/cryptography. The idea is that cryptography is
built on computing complexity and not on Java itself. And here the Java lost
reputation and renewed again with Java 8 as fixed number of bugs. I can
clearly see in my company - they are shaking on the chair, what would happen
with new version of JRE and I calm their down saying that JRE 8 already
solved known bugs reported against in JRE7.
Maybe the same should happen with Maven, who knows. :-)
--
View this message in context: http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838755.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
User Community was (Re: number of bugs in maven-release-plugin)
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Robert,
On 6/27/15 12:51 PM, robert.patrick@oracle.com wrote:
> Sorry for butting in but as someone who is a staunch supporter of
> Maven within my company and its user community,
> I have to agree that the difficulty in engaging
> the Maven developers to even discuss issues
> is too high.
First i would be interested in examples of this kind, cause
unfortunately i have to say i never saw your name on the dev/users
list...nor can i remember about your name in jira issue (I have admit
that i'm not that long part of the Maven team but i'm reading the list a
longer time)..may be just i oversight or mistaken something....
> I often find myself fixing plugins by forking
> my own private versions since doing
> anything else is too slow/painful.
Can you give some examples (or a list of them) of those fixes and for
which plugins you have to do so? And how often in number is ?
>
> Sorry for the intrusion...
No excuse needed and that's no intrusion.......
It is very important that someone raises his hand that there is
something which need to pay attention to....
>
> Robert Patrick <ro...@oracle.com>
> VP, Oracle Corporation
> Mobile: +1.469.556.9450
> Sent from my iDevice
>
> On Jun 27, 2015, at 5:36 PM, Tibor Digana <ti...@apache.org> wrote:
>
>>>> 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.
The problem of many patches is simply they lack of tests, i often write
to them they should produce tests...but i often get the feedback: I
don't have time to write test just fix it...or i don't get any feedback
at all...
Furthermore as Robert Scholte mentioned people often see only their
limited scope which often conflicts with the whole idea's, concept of
Maven / Plugins in general...which results in not acceptiong 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.
Which would exactly results in coded builds which is in the end much
more complicated and worse maintainable than any Maven build every be....
> 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?
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: number of bugs in maven-release-plugin
Posted by "robert.patrick@oracle.com" <ro...@oracle.com>.
Sorry for butting in but as someone who is a staunch supporter of Maven within my company and its user community, I have to agree that the difficulty in engaging the Maven developers to even discuss issues is too high. I often find myself fixing plugins by forking my own private versions since doing anything else is too slow/painful.
Sorry for the intrusion...
Robert Patrick <ro...@oracle.com>
VP, Oracle Corporation
Mobile: +1.469.556.9450
Sent from my iDevice
On Jun 27, 2015, at 5:36 PM, Tibor Digana <ti...@apache.org> wrote:
>>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: number of bugs in maven-release-plugin
Posted by Tibor Digana <ti...@apache.org>.
>> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: number of bugs in maven-release-plugin
Posted by Robert Scholte <rf...@apache.org>.
It was even worse.
When I joined this team I started working on this plugin and managed to
close half of them ( let's say from 300 back to 150 issues).
Right now there's a situation where new issues are often easy to reproduce.
The older ones are often harder to reproduce or are already fixed.
I've already asked for feedback for a lot of issues. If I go through that
list again,I'm pretty sure I can close a lot again.
Then there are some issues which require some redesign, but without good
code coverage it is hard to discover regression.
For instance, I'd like to replace jdom with woodstox, because there are a
lot of hacks in the code to please jdom.
When I'm done with the M3 plugin migration I'd love to pick it up again.
Then there's this tricky thing that it should work for all SCM's. It's
great that maven-scm is a separate project, but that might need even more
attention. But then we hit the problem that there's not enough knowledge
for all these systems. 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).
thanks,
Robert
Op Fri, 26 Jun 2015 22:55:02 +0200 schreef Tibor Digana
<ti...@apache.org>:
> Do you know what's wrong with Jira on maven-release-plugin MRELEASE?
> It's growing nearly to 200 open bugs. It looks like the community use to
> fix 5 in each release. Maybe the community should start closing
> irrelevant
> bugs which better helps concentrating on more relevant bugs.
>
> We started this strategy in surefire plugin and closed irrelevant bugs.
> This iteration has happened several times already. Then we released cca
> 30
> fixed issues in every major release. This way we are now under 100 open
> issues and still cutting the bugs down.
> I have a strategy to handle new bug as it comes in Jira and ask the
> originator to fix it and offering some hints to him/her. This way we have
> got few more contributors in surefire project. Even if the contributor
> does
> not implement properly, it always saves my time and I can still modify
> his
> implementation or ask him to reimplement it.
>
> Maybe it's the only question if we really want to have better statistics
> and fix more bugs.
> Maybe it's a question of resources like number of committers. We have
> some
> contributors on GitHub, so maybe it is as simple as to ask them get this
> position.
>
> Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org