You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Oleg Gusakov <ol...@gmail.com> on 2008/12/17 01:03:25 UTC
sometimes too much help is not helping - r725533
Brett,
Please don't change the code you don't understand without, at least,
consulting people who work on it.
I lost entire day between yesterday and today, trying to understand why
my unit tests suddenly stopped working. They traced to your commit
r725533 which emptied jar files in mercury-ant-tasks! Unit tests were
using those jars to compile test code.
I appreciate the help, but help that adds value to the project, not
hinders it. Take, for example, Ben - he found a bug and posted the
solution in jira, because he was not sure that it can break tests. It
did break them, but together we found the solution (btw - he was right).
Our team is very responsive, and posting problem in jira usually gets
them resolved.
Thanks,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: sometimes too much help is not helping - r725533
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
There is only one team, the Maven team.
However I think it's fair to ask that people be careful when changing
things that are being actively developed by another person, at least
over-communicate to avoid collisions. AFAIK, the issue was resolved
already by both sides.
-----Original Message-----
From: Arnaud HERITIER [mailto:aheritier@gmail.com]
Sent: Wednesday, December 17, 2008 9:58 AM
To: Maven Developers List
Subject: Re: sometimes too much help is not helping - r725533
Hi,
In this thread you are talking about several teams. I'm considering
there
is only one maven team. If this not the case is there someone who can
explain to me which teams we have and who is working in which ?
cheers
Arnaud.
On Wed, Dec 17, 2008 at 4:19 AM, Oleg Gusakov
<ol...@gmail.com>wrote:
> Brett,
>
> Trust me, I don't enjoy this discussion no more that you, but I have
to
> respond.
>
> Brett Porter wrote:
>
>> I'm sorry you lost some time investigating it, but I made every
attempt to
>> do this properly.
>>
>> At the time I made the change, I cleaned out the checkout and did a
build
>> without getting any test errors. This was confirmed by the grid:
>> https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/
>>
>> It appears your change to test using compilation was only checked in
>> afterwards. I'm afraid I'm still working on my ability to predict the
future
>> :)
>>
> This statement suggests that I am a dumb coder, who submits tons of
jars to
> SVN for the pleasure of just having them there. I admit that I did not
> commit the tests using those jars right away.
>
> But give me some credit: everything has a reason. And if this reason
is not
> clear - ask, don't assume you know everything and can improve without
> knowing. I did acknowledge your suggestion about the size of test
repo, and
> started fixing it. If you would have just suggested the solution,
provided a
> script in jira - that would only raise a lot of gratitude.
>
> But hindering a pre-alpha quality project by assuming things and
changing
> still unstable data, this is simply not fair. Losing a day over such a
> trivial matter - I simply did not expect anyone to do such a thing.
>
> I apologize if this sounds harsh, but believe me - the sole purpose is
to
> improve our process, make sure that this does not happen in the
future.
>
> So the proposal is: change the rules to say the following: "if you
don't
> work on an actively developed project - don't start modifying it
without
> consulting the team, working on it. If you do find a bug or
improvement -
> communicate with developers via issue tracking system and other means"
This
> is not predicting the future - just common sense.
>
> Thanks,
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
..........................................................
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..........................................................
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..........................................................
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...........................................................
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: sometimes too much help is not helping - r725533
Posted by Oleg Gusakov <ol...@gmail.com>.
Jason van Zyl wrote:
>
> On 17-Dec-08, at 9:57 AM, Arnaud HERITIER wrote:
>
>> Hi,
>>
>> In this thread you are talking about several teams. I'm considering
>> there
>> is only one maven team. If this not the case is there someone who can
>> explain to me which teams we have and who is working in which ?
>>
>
> Obviously there are people working on Mercury, Maven, Doxia, Maven
> SCM. In this particular case Oleg was referring to himself and
> Benjamin as that's what's formed around Mercury.
>
Actually, Benjamen, Herve and myself is the group of people I was
referring to.
Overall: guys - Brett and I came to conclusion that it's a mere common
sense to communicate any changes via jira, and that is good to simply
talk from time to time. Case closed, court adjourned :)
Cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: sometimes too much help is not helping - r725533
Posted by Jason van Zyl <jv...@sonatype.com>.
I think Oleg answered the Mercury question: currently himself, Hervé
and Ben.
On 17-Dec-08, at 2:55 PM, Arnaud HERITIER wrote:
> Hi Jason,
>
> I know that we have several sub-projects and in parallel we have more
> people working on it (or more precisely I think we have not really
> more
> people but those one are working more because it's part of there
> job). What
> I asked was who was in those teams/subprojects to better understand
> our
> project. I have to admit it's difficult when we aren't working on
> maven each
> day to know who is working on what and more especially on new
> projects like
> mercury...
>
> Cheers,
>
> Arnaud
>
> On Wed, Dec 17, 2008 at 4:57 PM, Jason van Zyl
> <jv...@sonatype.com> wrote:
>
>>
>> On 17-Dec-08, at 9:57 AM, Arnaud HERITIER wrote:
>>
>> Hi,
>>>
>>> In this thread you are talking about several teams. I'm
>>> considering there
>>> is only one maven team. If this not the case is there someone who
>>> can
>>> explain to me which teams we have and who is working in which ?
>>>
>>>
>> Obviously there are people working on Mercury, Maven, Doxia, Maven
>> SCM. In
>> this particular case Oleg was referring to himself and Benjamin as
>> that's
>> what's formed around Mercury. It really boils down to some commons
>> sense and
>> respect.
>>
>> Arnaud, at Octo you are one company and probably have many
>> projects. Do
>> you, while not being heavily active or not at all, walk into another
>> consultants project and change things that break tests? I seriously
>> doubt
>> it. It's not any different here. The patterns that form in the real
>> world
>> actually apply here as well. You probably have different people
>> working on
>> different things. You work together as a community even at work,
>> like we do
>> here. You work together to service your users or clients, like we
>> do here.
>> You probably don't obstruct your co-workings from getting their
>> work done.
>> Apache is not some magical place where these basic constructs just
>> disappear. Groups form naturally, teams within teams.
>>
>> Teams, these groups that form, communicate if they want to be
>> effective.
>> And that is the crux of Oleg's argument.
>>
>> The beauty of Apache is that everyone has the potential to
>> contribute as
>> much as they wish. Not that you are instantly equal because you are a
>> committer on a project. To believe that you negate all meritocracy
>> and show
>> little or no respect for the person who contributes the most for
>> whatever
>> reason is not acceptable to me. It's just basic common sense, and the
>> pattern that every successful community in the world exhibits. Just
>> give a
>> heads up is what it boils down to and that's all Oleg was asking for.
>>
>>
>> cheers
>>>
>>> Arnaud.
>>>
>>> On Wed, Dec 17, 2008 at 4:19 AM, Oleg Gusakov
>>> <ol...@gmail.com>wrote:
>>>
>>> Brett,
>>>>
>>>> Trust me, I don't enjoy this discussion no more that you, but I
>>>> have to
>>>> respond.
>>>>
>>>> Brett Porter wrote:
>>>>
>>>> I'm sorry you lost some time investigating it, but I made every
>>>> attempt
>>>>> to
>>>>> do this properly.
>>>>>
>>>>> At the time I made the change, I cleaned out the checkout and
>>>>> did a
>>>>> build
>>>>> without getting any test errors. This was confirmed by the grid:
>>>>> https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/
>>>>>
>>>>> It appears your change to test using compilation was only
>>>>> checked in
>>>>> afterwards. I'm afraid I'm still working on my ability to
>>>>> predict the
>>>>> future
>>>>> :)
>>>>>
>>>>> This statement suggests that I am a dumb coder, who submits tons
>>>>> of
>>>> jars to
>>>> SVN for the pleasure of just having them there. I admit that I
>>>> did not
>>>> commit the tests using those jars right away.
>>>>
>>>> But give me some credit: everything has a reason. And if this
>>>> reason is
>>>> not
>>>> clear - ask, don't assume you know everything and can improve
>>>> without
>>>> knowing. I did acknowledge your suggestion about the size of test
>>>> repo,
>>>> and
>>>> started fixing it. If you would have just suggested the solution,
>>>> provided a
>>>> script in jira - that would only raise a lot of gratitude.
>>>>
>>>> But hindering a pre-alpha quality project by assuming things and
>>>> changing
>>>> still unstable data, this is simply not fair. Losing a day over
>>>> such a
>>>> trivial matter - I simply did not expect anyone to do such a thing.
>>>>
>>>> I apologize if this sounds harsh, but believe me - the sole
>>>> purpose is to
>>>> improve our process, make sure that this does not happen in the
>>>> future.
>>>>
>>>> So the proposal is: change the rules to say the following: "if
>>>> you don't
>>>> work on an actively developed project - don't start modifying it
>>>> without
>>>> consulting the team, working on it. If you do find a bug or
>>>> improvement -
>>>> communicate with developers via issue tracking system and other
>>>> means"
>>>> This
>>>> is not predicting the future - just common sense.
>>>>
>>>> Thanks,
>>>> Oleg
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> ..........................................................
>>> Arnaud HERITIER
>>> 12 guidelines to boost your productivity with a Java software
>>> factory -
>>> http://tinyurl.com/56s9tw
>>> ..........................................................
>>> OCTO Technology - aheritier AT octo DOT com
>>> www.octo.com | blog.octo.com
>>> ..........................................................
>>> ASF - aheritier AT apache DOT org
>>> www.apache.org | maven.apache.org
>>> ...........................................................
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> the course of true love never did run smooth ...
>>
>> -- Shakespeare
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> ..........................................................
> Arnaud HERITIER
> 12 guidelines to boost your productivity with a Java software
> factory -
> http://tinyurl.com/56s9tw
> ..........................................................
> OCTO Technology - aheritier AT octo DOT com
> www.octo.com | blog.octo.com
> ..........................................................
> ASF - aheritier AT apache DOT org
> www.apache.org | maven.apache.org
> ...........................................................
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: sometimes too much help is not helping - r725533
Posted by Arnaud HERITIER <ah...@gmail.com>.
Hi Jason,
I know that we have several sub-projects and in parallel we have more
people working on it (or more precisely I think we have not really more
people but those one are working more because it's part of there job). What
I asked was who was in those teams/subprojects to better understand our
project. I have to admit it's difficult when we aren't working on maven each
day to know who is working on what and more especially on new projects like
mercury...
Cheers,
Arnaud
On Wed, Dec 17, 2008 at 4:57 PM, Jason van Zyl <jv...@sonatype.com> wrote:
>
> On 17-Dec-08, at 9:57 AM, Arnaud HERITIER wrote:
>
> Hi,
>>
>> In this thread you are talking about several teams. I'm considering there
>> is only one maven team. If this not the case is there someone who can
>> explain to me which teams we have and who is working in which ?
>>
>>
> Obviously there are people working on Mercury, Maven, Doxia, Maven SCM. In
> this particular case Oleg was referring to himself and Benjamin as that's
> what's formed around Mercury. It really boils down to some commons sense and
> respect.
>
> Arnaud, at Octo you are one company and probably have many projects. Do
> you, while not being heavily active or not at all, walk into another
> consultants project and change things that break tests? I seriously doubt
> it. It's not any different here. The patterns that form in the real world
> actually apply here as well. You probably have different people working on
> different things. You work together as a community even at work, like we do
> here. You work together to service your users or clients, like we do here.
> You probably don't obstruct your co-workings from getting their work done.
> Apache is not some magical place where these basic constructs just
> disappear. Groups form naturally, teams within teams.
>
> Teams, these groups that form, communicate if they want to be effective.
> And that is the crux of Oleg's argument.
>
> The beauty of Apache is that everyone has the potential to contribute as
> much as they wish. Not that you are instantly equal because you are a
> committer on a project. To believe that you negate all meritocracy and show
> little or no respect for the person who contributes the most for whatever
> reason is not acceptable to me. It's just basic common sense, and the
> pattern that every successful community in the world exhibits. Just give a
> heads up is what it boils down to and that's all Oleg was asking for.
>
>
> cheers
>>
>> Arnaud.
>>
>> On Wed, Dec 17, 2008 at 4:19 AM, Oleg Gusakov
>> <ol...@gmail.com>wrote:
>>
>> Brett,
>>>
>>> Trust me, I don't enjoy this discussion no more that you, but I have to
>>> respond.
>>>
>>> Brett Porter wrote:
>>>
>>> I'm sorry you lost some time investigating it, but I made every attempt
>>>> to
>>>> do this properly.
>>>>
>>>> At the time I made the change, I cleaned out the checkout and did a
>>>> build
>>>> without getting any test errors. This was confirmed by the grid:
>>>> https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/
>>>>
>>>> It appears your change to test using compilation was only checked in
>>>> afterwards. I'm afraid I'm still working on my ability to predict the
>>>> future
>>>> :)
>>>>
>>>> This statement suggests that I am a dumb coder, who submits tons of
>>> jars to
>>> SVN for the pleasure of just having them there. I admit that I did not
>>> commit the tests using those jars right away.
>>>
>>> But give me some credit: everything has a reason. And if this reason is
>>> not
>>> clear - ask, don't assume you know everything and can improve without
>>> knowing. I did acknowledge your suggestion about the size of test repo,
>>> and
>>> started fixing it. If you would have just suggested the solution,
>>> provided a
>>> script in jira - that would only raise a lot of gratitude.
>>>
>>> But hindering a pre-alpha quality project by assuming things and changing
>>> still unstable data, this is simply not fair. Losing a day over such a
>>> trivial matter - I simply did not expect anyone to do such a thing.
>>>
>>> I apologize if this sounds harsh, but believe me - the sole purpose is to
>>> improve our process, make sure that this does not happen in the future.
>>>
>>> So the proposal is: change the rules to say the following: "if you don't
>>> work on an actively developed project - don't start modifying it without
>>> consulting the team, working on it. If you do find a bug or improvement -
>>> communicate with developers via issue tracking system and other means"
>>> This
>>> is not predicting the future - just common sense.
>>>
>>> Thanks,
>>> Oleg
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
>> --
>> ..........................................................
>> Arnaud HERITIER
>> 12 guidelines to boost your productivity with a Java software factory -
>> http://tinyurl.com/56s9tw
>> ..........................................................
>> OCTO Technology - aheritier AT octo DOT com
>> www.octo.com | blog.octo.com
>> ..........................................................
>> ASF - aheritier AT apache DOT org
>> www.apache.org | maven.apache.org
>> ...........................................................
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> the course of true love never did run smooth ...
>
> -- Shakespeare
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
..........................................................
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..........................................................
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..........................................................
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...........................................................
Re: sometimes too much help is not helping - r725533
Posted by Jason van Zyl <jv...@sonatype.com>.
On 17-Dec-08, at 9:57 AM, Arnaud HERITIER wrote:
> Hi,
>
> In this thread you are talking about several teams. I'm considering
> there
> is only one maven team. If this not the case is there someone who can
> explain to me which teams we have and who is working in which ?
>
Obviously there are people working on Mercury, Maven, Doxia, Maven
SCM. In this particular case Oleg was referring to himself and
Benjamin as that's what's formed around Mercury. It really boils down
to some commons sense and respect.
Arnaud, at Octo you are one company and probably have many projects.
Do you, while not being heavily active or not at all, walk into
another consultants project and change things that break tests? I
seriously doubt it. It's not any different here. The patterns that
form in the real world actually apply here as well. You probably have
different people working on different things. You work together as a
community even at work, like we do here. You work together to service
your users or clients, like we do here. You probably don't obstruct
your co-workings from getting their work done. Apache is not some
magical place where these basic constructs just disappear. Groups form
naturally, teams within teams.
Teams, these groups that form, communicate if they want to be
effective. And that is the crux of Oleg's argument.
The beauty of Apache is that everyone has the potential to contribute
as much as they wish. Not that you are instantly equal because you are
a committer on a project. To believe that you negate all meritocracy
and show little or no respect for the person who contributes the most
for whatever reason is not acceptable to me. It's just basic common
sense, and the pattern that every successful community in the world
exhibits. Just give a heads up is what it boils down to and that's all
Oleg was asking for.
> cheers
>
> Arnaud.
>
> On Wed, Dec 17, 2008 at 4:19 AM, Oleg Gusakov
> <ol...@gmail.com>wrote:
>
>> Brett,
>>
>> Trust me, I don't enjoy this discussion no more that you, but I
>> have to
>> respond.
>>
>> Brett Porter wrote:
>>
>>> I'm sorry you lost some time investigating it, but I made every
>>> attempt to
>>> do this properly.
>>>
>>> At the time I made the change, I cleaned out the checkout and did
>>> a build
>>> without getting any test errors. This was confirmed by the grid:
>>> https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/
>>>
>>> It appears your change to test using compilation was only checked in
>>> afterwards. I'm afraid I'm still working on my ability to predict
>>> the future
>>> :)
>>>
>> This statement suggests that I am a dumb coder, who submits tons of
>> jars to
>> SVN for the pleasure of just having them there. I admit that I did
>> not
>> commit the tests using those jars right away.
>>
>> But give me some credit: everything has a reason. And if this
>> reason is not
>> clear - ask, don't assume you know everything and can improve without
>> knowing. I did acknowledge your suggestion about the size of test
>> repo, and
>> started fixing it. If you would have just suggested the solution,
>> provided a
>> script in jira - that would only raise a lot of gratitude.
>>
>> But hindering a pre-alpha quality project by assuming things and
>> changing
>> still unstable data, this is simply not fair. Losing a day over
>> such a
>> trivial matter - I simply did not expect anyone to do such a thing.
>>
>> I apologize if this sounds harsh, but believe me - the sole purpose
>> is to
>> improve our process, make sure that this does not happen in the
>> future.
>>
>> So the proposal is: change the rules to say the following: "if you
>> don't
>> work on an actively developed project - don't start modifying it
>> without
>> consulting the team, working on it. If you do find a bug or
>> improvement -
>> communicate with developers via issue tracking system and other
>> means" This
>> is not predicting the future - just common sense.
>>
>> Thanks,
>> Oleg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> ..........................................................
> Arnaud HERITIER
> 12 guidelines to boost your productivity with a Java software
> factory -
> http://tinyurl.com/56s9tw
> ..........................................................
> OCTO Technology - aheritier AT octo DOT com
> www.octo.com | blog.octo.com
> ..........................................................
> ASF - aheritier AT apache DOT org
> www.apache.org | maven.apache.org
> ...........................................................
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: sometimes too much help is not helping - r725533
Posted by Arnaud HERITIER <ah...@gmail.com>.
Hi,
In this thread you are talking about several teams. I'm considering there
is only one maven team. If this not the case is there someone who can
explain to me which teams we have and who is working in which ?
cheers
Arnaud.
On Wed, Dec 17, 2008 at 4:19 AM, Oleg Gusakov
<ol...@gmail.com>wrote:
> Brett,
>
> Trust me, I don't enjoy this discussion no more that you, but I have to
> respond.
>
> Brett Porter wrote:
>
>> I'm sorry you lost some time investigating it, but I made every attempt to
>> do this properly.
>>
>> At the time I made the change, I cleaned out the checkout and did a build
>> without getting any test errors. This was confirmed by the grid:
>> https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/
>>
>> It appears your change to test using compilation was only checked in
>> afterwards. I'm afraid I'm still working on my ability to predict the future
>> :)
>>
> This statement suggests that I am a dumb coder, who submits tons of jars to
> SVN for the pleasure of just having them there. I admit that I did not
> commit the tests using those jars right away.
>
> But give me some credit: everything has a reason. And if this reason is not
> clear - ask, don't assume you know everything and can improve without
> knowing. I did acknowledge your suggestion about the size of test repo, and
> started fixing it. If you would have just suggested the solution, provided a
> script in jira - that would only raise a lot of gratitude.
>
> But hindering a pre-alpha quality project by assuming things and changing
> still unstable data, this is simply not fair. Losing a day over such a
> trivial matter - I simply did not expect anyone to do such a thing.
>
> I apologize if this sounds harsh, but believe me - the sole purpose is to
> improve our process, make sure that this does not happen in the future.
>
> So the proposal is: change the rules to say the following: "if you don't
> work on an actively developed project - don't start modifying it without
> consulting the team, working on it. If you do find a bug or improvement -
> communicate with developers via issue tracking system and other means" This
> is not predicting the future - just common sense.
>
> Thanks,
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
..........................................................
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..........................................................
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..........................................................
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...........................................................
Re: sometimes too much help is not helping - r725533
Posted by Brett Porter <br...@apache.org>.
Oleg and I sorted out the misunderstanding offline. It's all good.
- Brett
On 17/12/2008, at 2:19 PM, Oleg Gusakov wrote:
> Brett,
>
> Trust me, I don't enjoy this discussion no more that you, but I have
> to respond.
>
> Brett Porter wrote:
>> I'm sorry you lost some time investigating it, but I made every
>> attempt to do this properly.
>>
>> At the time I made the change, I cleaned out the checkout and did a
>> build without getting any test errors. This was confirmed by the
>> grid: https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/
>>
>> It appears your change to test using compilation was only checked
>> in afterwards. I'm afraid I'm still working on my ability to
>> predict the future :)
> This statement suggests that I am a dumb coder, who submits tons of
> jars to SVN for the pleasure of just having them there. I admit that
> I did not commit the tests using those jars right away.
>
> But give me some credit: everything has a reason. And if this reason
> is not clear - ask, don't assume you know everything and can improve
> without knowing. I did acknowledge your suggestion about the size of
> test repo, and started fixing it. If you would have just suggested
> the solution, provided a script in jira - that would only raise a
> lot of gratitude.
>
> But hindering a pre-alpha quality project by assuming things and
> changing still unstable data, this is simply not fair. Losing a day
> over such a trivial matter - I simply did not expect anyone to do
> such a thing.
>
> I apologize if this sounds harsh, but believe me - the sole purpose
> is to improve our process, make sure that this does not happen in
> the future.
>
> So the proposal is: change the rules to say the following: "if you
> don't work on an actively developed project - don't start modifying
> it without consulting the team, working on it. If you do find a bug
> or improvement - communicate with developers via issue tracking
> system and other means" This is not predicting the future - just
> common sense.
>
> Thanks,
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: sometimes too much help is not helping - r725533
Posted by Oleg Gusakov <ol...@gmail.com>.
Brett,
Trust me, I don't enjoy this discussion no more that you, but I have to
respond.
Brett Porter wrote:
> I'm sorry you lost some time investigating it, but I made every
> attempt to do this properly.
>
> At the time I made the change, I cleaned out the checkout and did a
> build without getting any test errors. This was confirmed by the grid:
> https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/
>
> It appears your change to test using compilation was only checked in
> afterwards. I'm afraid I'm still working on my ability to predict the
> future :)
This statement suggests that I am a dumb coder, who submits tons of jars
to SVN for the pleasure of just having them there. I admit that I did
not commit the tests using those jars right away.
But give me some credit: everything has a reason. And if this reason is
not clear - ask, don't assume you know everything and can improve
without knowing. I did acknowledge your suggestion about the size of
test repo, and started fixing it. If you would have just suggested the
solution, provided a script in jira - that would only raise a lot of
gratitude.
But hindering a pre-alpha quality project by assuming things and
changing still unstable data, this is simply not fair. Losing a day over
such a trivial matter - I simply did not expect anyone to do such a thing.
I apologize if this sounds harsh, but believe me - the sole purpose is
to improve our process, make sure that this does not happen in the future.
So the proposal is: change the rules to say the following: "if you don't
work on an actively developed project - don't start modifying it without
consulting the team, working on it. If you do find a bug or improvement
- communicate with developers via issue tracking system and other means"
This is not predicting the future - just common sense.
Thanks,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: sometimes too much help is not helping - r725533
Posted by Brett Porter <br...@apache.org>.
On 17/12/2008, at 11:03 AM, Oleg Gusakov wrote:
> Brett,
>
> Please don't change the code you don't understand without, at least,
> consulting people who work on it.
I did try... http://markmail.org/message/ifkbjf3rb24z3wvb
I have a good understanding of how the code works. Outside of the
Jetty client, I think I may be the only person (with the possible
exception of Jason) that has given it a decent look over at this
point. I'm still seeking you're enlightenment on the pieces I didn't
understand: http://markmail.org/message/tibxv4f7di2caj2y, and am still
looking forward to your response.
>
>
> I lost entire day between yesterday and today, trying to understand
> why my unit tests suddenly stopped working. They traced to your
> commit r725533 which emptied jar files in mercury-ant-tasks! Unit
> tests were using those jars to compile test code.
I'm sorry you lost some time investigating it, but I made every
attempt to do this properly.
At the time I made the change, I cleaned out the checkout and did a
build without getting any test errors. This was confirmed by the grid: https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/
It appears your change to test using compilation was only checked in
afterwards. I'm afraid I'm still working on my ability to predict the
future :)
Certainly if it had been a functional change I'd have spent more time
in consultation as you suggested. The example you gave from Benjamin
is certainly a good way for things to work. We all need to tread
lightly in unfamiliar territory, and I understand that. I have no
desire to look like an idiot through inexperience if I can avoid it.
Anyway, thanks for fixing up the size of the test repo even in the
"reversion". I do appreciate it.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Decoupling from Compilation
Posted by Benjamin Bentmann <be...@udo.edu>.
Oleg Gusakov wrote:
> Test performance: 100s of millis added by the compiler do not add too
> much of a delay; the compilation unit is a 2-liner.
Yep, it's surely of minor concern for the Mercury tests themselves. But
just imagine a penalty of about 1 sec and scale this by 250 and you get
an idea what other test suites are spending their time on...
> Did I sound convincing?
You don't need to, I was merely making a suggestion, you're the
maintainer ;-).
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Decoupling from Compilation
Posted by Oleg Gusakov <ol...@gmail.com>.
Benjamin Bentmann wrote:
> Oleg Gusakov wrote:
>
>> Unit tests were using those jars to compile test code.
>
> Just a technical question: Is it actually required/desirable to really
> compile code during the tests?
>
> Over in the Maven core ITs, running the Compiler (or Surefire) Plugin
> was the classical approach to test dependency resolution. IMHO, this
> approach adds
> a) unnecessary coupling with external components
> b) unnecessary complexity to the tests
> not to mention the performance penalty.
>
> To come back to Mercury, you are now about to chase down why the
> compiler isn't found (MERCURY-61). But as far as I understand the Ant
> tasks are concerned about dependency resolution, i.e. getting JARs,
> not compilation.
>
> So, wouldn't it be feasible to
> 1) Have the Ant tasks resolve the dependencies
> 2) Dump the resulting class path to a file (<echo>, custom test task)
> 3) Have the test controller (and not a compiler) verify the
> order/contents of the class path by reading that file
> ?
This will prove only so much. All my previous experience says that if
there is a small crack an error can squeeze through, it will :) This
task is supposed to provide a compiler with a classpath, if I start
interpreting the path - I might do it differently from the compiler and
allow an error.
So - if this is supposed to give compiler a classpath - let compiler be
the judge. I hear your "unnecessary complexity to the tests" argument,
but I think that long term it's s lesser price to pay, compared to a
possibility of an error, undetectable without a compiler.
Test performance: 100s of millis added by the compiler do not add too
much of a delay; the compilation unit is a 2-liner.
Did I sound convincing?
Oleg
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> 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: Decoupling from Compilation was: sometimes too much help is not
helping - r725533
Posted by Oleg Gusakov <ol...@gmail.com>.
Herve,
Hervé BOUTEMY wrote:
> Le mercredi 17 décembre 2008, Benjamin Bentmann a écrit :
>
>> Oleg Gusakov wrote:
>>
>>> Unit tests were using those jars to compile test code.
>>>
>> Just a technical question: Is it actually required/desirable to really
>> compile code during the tests?
>>
>> Over in the Maven core ITs, running the Compiler (or Surefire) Plugin
>> was the classical approach to test dependency resolution. IMHO, this
>> approach adds
>> a) unnecessary coupling with external components
>> b) unnecessary complexity to the tests
>> not to mention the performance penalty.
>>
>> To come back to Mercury, you are now about to chase down why the
>> compiler isn't found (MERCURY-61). But as far as I understand the Ant
>> tasks are concerned about dependency resolution, i.e. getting JARs, not
>> compilation.
>>
>> So, wouldn't it be feasible to
>> 1) Have the Ant tasks resolve the dependencies
>> 2) Dump the resulting class path to a file (<echo>, custom test task)
>> 3) Have the test controller (and not a compiler) verify the
>> order/contents of the class path by reading that file
>> ?
>>
> just for the record, I did such tests:
>
> 1. in Maven Ant Tasks: see sample.build.xml target "test-deps-order", which is
> based on <pathconvert> task
>
> 2. in MNG-1412 IT, with java code getResources( "META-INF/MANIFEST.MF" )
>
>
You suggestion duly noted :)
I think that testing entire workflow end to end at least once in UTs is
crucial. I don't abuse it - in all other unit tests I just resolve
artifacts and check for their presence in the local repository, which is
cleaned before every test. But doing full compile once is essential.
I am exploring the last problem - pgp read validation fails on Vista,
but works everywhere else, including WinXP.
Thanks,
Oleg
> Regards,
>
> Hervé
>
>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> 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: Decoupling from Compilation was: sometimes too much help is not helping - r725533
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mercredi 17 décembre 2008, Benjamin Bentmann a écrit :
> Oleg Gusakov wrote:
> > Unit tests were using those jars to compile test code.
>
> Just a technical question: Is it actually required/desirable to really
> compile code during the tests?
>
> Over in the Maven core ITs, running the Compiler (or Surefire) Plugin
> was the classical approach to test dependency resolution. IMHO, this
> approach adds
> a) unnecessary coupling with external components
> b) unnecessary complexity to the tests
> not to mention the performance penalty.
>
> To come back to Mercury, you are now about to chase down why the
> compiler isn't found (MERCURY-61). But as far as I understand the Ant
> tasks are concerned about dependency resolution, i.e. getting JARs, not
> compilation.
>
> So, wouldn't it be feasible to
> 1) Have the Ant tasks resolve the dependencies
> 2) Dump the resulting class path to a file (<echo>, custom test task)
> 3) Have the test controller (and not a compiler) verify the
> order/contents of the class path by reading that file
> ?
just for the record, I did such tests:
1. in Maven Ant Tasks: see sample.build.xml target "test-deps-order", which is
based on <pathconvert> task
2. in MNG-1412 IT, with java code getResources( "META-INF/MANIFEST.MF" )
Regards,
Hervé
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> 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: Decoupling from Compilation was: sometimes too much help is not
helping - r725533
Posted by Benjamin Bentmann <be...@udo.edu>.
Oleg Gusakov wrote:
> Unit tests were using those jars to compile test code.
Just a technical question: Is it actually required/desirable to really
compile code during the tests?
Over in the Maven core ITs, running the Compiler (or Surefire) Plugin
was the classical approach to test dependency resolution. IMHO, this
approach adds
a) unnecessary coupling with external components
b) unnecessary complexity to the tests
not to mention the performance penalty.
To come back to Mercury, you are now about to chase down why the
compiler isn't found (MERCURY-61). But as far as I understand the Ant
tasks are concerned about dependency resolution, i.e. getting JARs, not
compilation.
So, wouldn't it be feasible to
1) Have the Ant tasks resolve the dependencies
2) Dump the resulting class path to a file (<echo>, custom test task)
3) Have the test controller (and not a compiler) verify the
order/contents of the class path by reading that file
?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org