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:aherit...@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 <oleg.subscripti...@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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
