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 <jvan...@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 >> <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 >> ........................................................... >> > > 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-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 ...........................................................
