On Nov 2, 2010, at 9:23 AM, Brett Porter wrote: > > On 01/11/2010, at 10:26 PM, Brian Fox wrote: > >>> The barrier to collaboration is high here. >> >> That's all I'm saying. The tools make that partially true but it's not >> stopping other projects so it's clearly not the only issue. Maybe no >> one really cares about these plugins, and for the ones raised so far, >> that's probably the case. > > > The problem here is the way in which we abuse JIRA (by necessity). A change > of source control would make little difference, other than if it were to > route around issue tracking which isn't particularly helpful. Some people > watch patches on specific subprojects, other subprojects get neglected > (perhaps picked up in bursts). Not all such subprojects are retirable.
I completely disagree. What evidence do you have to counter my assertion? In Tycho and Polyglot, which are in Git, we have two projects that have had a huge number of contributions from external parties. In Tycho we have 1/3 of the work done by the community. 1/3! In Polyglot Maven I have had people come out of the blue and make dialects and heavily patch the guts. I have evidence of higher contributions and I can tell you from first hand experience how easy it is to have some one clone a repo and then submit a pull request. They sign a CLA and I pull back. Git absolutely makes the creation and absorption of changes easier. > > No other project I know of tracks small components in such a way, and we > regularly lose sight or timeliness of patches. IMO, we should reconsider our > approach, or look again at aggregation, or some way of keeping track of > patches across projects. Lots of project do, look at Eclipse. I'm here at the Eclipse Summit and folks are pretty adamant about Git helping with the process of acceleration contributions. > > The limiting factor is in time, communicating and testing, not in applying or > releasing them. I agree with time, which is greatly reduced by using Git. Of that there is no doubt. Linux, Debian, X.org, QT, and countless other projects have migrated to Git and will attest to the reduction in time it takes to process. Our testing is to a large extent automated now to at least catch stuff that will break Maven. No one takes the time to process the stuff or release it because it's obviously difficult in some way. > Those parts are about 10% at the start and end. The rest is in the middle, > and perhaps the pressure to fix more things while you are there. > No, I think it's mostly not seeing the patches and no one actively cultivating the patches to a useful state, waiting to long to process them and then they become impossible to try easily. I will demonstrate two counters in the next coming months with the Maven Shell and Polyglot Maven and I'll show you that the Maven community can thrive and will be attributable to using Git and the tooling like Github and Gerrit that have been built around it. The increased visibility of something simple like a pull request is an amazing thing. > - Brett > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------
