User Community was (Re: number of bugs in maven-release-plugin)

[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: User Community was (Re: number of bugs in maven-release-plugin)

[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)

[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)

["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)

[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