+0 with a long explanation
I'm really a friend of GIT in general. As some might remember I am even the guy who kicked off the GIT madness in maven land back in 2007 in the first place [1]. But I'm also a friend of using the right tool for the right job. GIT is great for projects which are not using dynamic modularity, because the concept of 'modules' is almost non-existing in GIT. I think GIT will work fine for maven-core and maven-scm, wagon or surefire which always get released as a whole. I think in those areas it would give us a certain benefit. But GIT sucks a bit when it comes to projects like maven-shared and maven-plugins which get released in portions. We already explained that with long words and we might have found a compromise which doesn't hurt too badly. But still it has to be verified if that works out. When it comes to community building I have my concerns that GIT will be of much benefit. We use GIT very successfully over in Apache DeltaSpike where it is very clear where the cannonical repository lives. If this is clear and all people know where they should get the main stuff from, then GIT is really great. And please forget about pull requests from some unknown github repos. We now count the year 1 after goog-vs-orcl and must really be cautious about intellectual property! This is just not possible because of the legal impacts as github doesnt check an authority of the authors. But here is another example where it did not work out: A few days ago a guy pinged us on #maven about the osxappbundle-maven-plugin. He just found 20++ versions around on github and none of them was working correctly. He didn't even know that the original one was still maintained in SVN in codehaus. So we went through all the versions on github and most of them contained different patches. And actually all of them only worked for a very specific situation. There was exactly 0 of them which worked on all 3 last OSX versions! What does this mean? If it's so much easier to make a private clone on github and fix exactly my own problem which I have right now, then this doesn't include feedback from others. And this not only bypasses the community but also confuses others. I'd really appreciate if people would be more careful with their clones and github would introduce a mandatory field [x] my original work [x] original code can be found: .... but that's another story. My summary: a project of that size is only working if there is a community around it. And whether you like a cannonical repo or not, it to some degrees forces users to talk with each others and give feedback! LieGrue, strub [1] https://github.com/struberg/maven-scm-providers-git/commit/e670863b2b03e158c59f34af1fee20f91b2bd852 ----- Original Message ----- > From: Olivier Lamy <ol...@apache.org> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Wednesday, September 5, 2012 1:04 PM > Subject: [VOTE] Move Maven projects sources to git > > Hi, > This vote is to decide moving our source tree currently located in one > svn repository to git (multiple git repositories). > First, we need to have at least 3 volunteers to help on Apache infra > for this move and more generally on git Apache infrastructure. (if you > are volunteer you must say that with your vote). > The vote will pass on majority (PMC committer) and if we have the > minimum of 3 volunteers ! > BTW contributors can express their opinion by a vote too ! > The vote will decide on moving all the source tree (volunteers time > will the main throttle). > > Volunteers will decide on what they move (notification on dev@ is mandatory). > The goal is to move simple projects first(scm,surefire, indexer,core, > wagon etc..) then plugins (except if Kristian want to start with > plugins immediately :-) ) > > Vote open for 72H. > > [+1] Move to git scm > [0] No interest > [-1] don't move to git (please explain why) > > > Thanks, > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org