maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Using GIT as the canonical repository for Maven 3.x
Date Fri, 24 Apr 2009 01:17:09 GMT
There are points on either side of this for me. In summary, I'm in  
favour of greater exploration of using GIT, but not a wholesale switch  

On 24/04/2009, at 3:00 AM, Jason van Zyl wrote:
> I'd be happy if everyone here wanted to use GIT but I do believe  
> that I have a better chance of getting people involved with Maven  
> 3.x if I can get the canonical repository in GIT.

Since this is the original subject, I'll address this first. First,  
let me be clear this is not an attack or conspiracy theory (I realise  
the timing with Nicolas' blog might make it sound that way), just how  
I See where we are today. So filter as necessary, I'm just in the mood  
to be blunt this week :)

Yes, DSCM may help get more people involved in Maven development which  
is a good thing. But first things first.

You have a better chance of getting people involved in Maven 3.x if  
you do what you said you'd do at the start, and required of others,  
and that is to have some documented intent. The wiki description is  
fairly vague and now outdated, and the direction has changed several  
times as has the bar for when it is "done enough" for others to  
participate. I learned the hard way in Maven 1.0 and Maven 2.0 that  
steaming ahead and relying on people to get involved on the other side  
just doesn't pan out. You have to make the development accessible, and  
that's about more than access to the source code.

 From what I see of the commits flying by, the technical direction  
looks exactly as I'd expect, but to be honest I have no clue why  
certain decisions get made, or what's happening next. You communicate  
with other developers working on trunk in forums inaccessible to other  
committers here, and don't bring the decisions back in forms other  
than code. I worry that a switch to git will make the temptation too  
great to start exchanging work directly with others, which despite  
some benefits will take others further out of the loop.

I'm convinced this would not take a great effort - 2 or 3 sentences  
every couple of days in an email would probably cover all the  
decisions made and plans changed.

I haven't had time to watch your presentation on your blog, and I  
expect it will help me understand where you're at today. But  
regardless, that sort of thing should be occurring here as well, and  
more frequently. I'm not asking that you seek 40-person consensus for  
anything, but tell us what you are doing and get some constructive  
feedback. That will greatly increase the chances of people being  
engaged, and getting involved at a point where it is practical. I  
expect most, like me, are sitting back waiting for that magic beta-1  
to re-engage, but we can have no expectation about when that really  
is, or what it takes to get there.

I know you genuinely want other people involved in the long run. If  
this all happened, and we have a thorough discussion about how it is  
executed, I'd have no issues with the use of git for trunk as a proof  
of concept.

Now that I've got that off my chest, back to git in general :) Some  
specific responses:

> In the Maven project we set precedent with JIRA and now I would like  
> to do that with GIT.
> If Apache Infrastructure doesn't want to support this then I feel we  
> can do the same thing we did with JIRA until they catch up. I think  
> having a canonical repository at Github is safe, well backed up and  
> maintained and I don't think we would have to worry about anything  
> there. They have full-time staff and a slew of engineers so I would  
> even argue that a repository at Github would be just as safe and  
> well maintained as a Subversion repository here.

I think it's a different climate now and we would better achieve this  
by working with Jukka and infra to build on the system already in  
place than shuffling off to external infrastructure. Having to  
maintain our own infra in the past has added pain as well as benefit.

I am strongly -1 to moving the canonical repository of code that is  
under our oversight off of ASF hardware.

On 24/04/2009, at 4:03 AM, Jason van Zyl wrote:

> The git-svn thing just sucks and is just hindrance to using GIT  
> properly.

Can you elaborate on why this is? There were things that were thought  
insurmountable to providing even dcommit initially, and others figured  
them out. Maybe there are other solutions that give us best of both  

> On 24/04/2009, at 9:21 AM, Brian Fox wrote:
>> Mark Struberg wrote:
>>> technically there is no git repo which is 'better' than the other.  
>>> This hierarchy is an orga one.
>>> If you can pull from my repo and from Jasons, from whom will you  
>>> pull your master mainly? Bet you will pull from Jasons. And I also  
>>> bet all contributors will try to get their changes being pulled by  
>>> Jason and published in his repo at the end of the day.
>> I think the canonical one would be equivalent to the current svn,  
>> where committers have access to push in changes. This would be  
>> required to maintain the "code provenance" but it would still make  
>> everyone's life easier to make changes and contribute them...and  
>> our lives easier to apply them.

Right, what Mark described is not how an ASF project works. Any  
methodology that starts making one person greater than another in the  
development group will not fly here.

A centralized git repo (or git-svn) that is considered the master that  
any of the committers can push to/pull from will fit our model, but we  
do need to realise that the increased flexibility in external  
branching comes with both positives and negatives. We do not want to  
start a slippery slope to where the development occurs outside this  

On 24/04/2009, at 4:13 AM, John Casey wrote:

> I will say that the maven-scm Git support - and the way it works  
> with the release plugin in particular - will have to improve before  
> we'll be able to work with Git easily. Specifically, doing releases  
> from a sub-tree of a Git repository is badly broken at the moment.  
> I've worked on this problem for a few hours all told up to this  
> point, and haven't found a workaround yet.

Right - a good reason for us to explore what we can do with it is to  
improve that support. I think it would be a mistake to get into a tool  
before we were fully up to scratch, but we also need some practical  
use to find the needs, positives and negatives as well.

We also need all the other bits in place like sending commit mails to  
the list and authorization based off Apache accounts. We need to  
consider the impact for backups and scalability and all that stuff. I  
know there are answers - but we can't fall into the trap of making  
assumptions either. Then there's other things we'd miss like SVNsearch  
and linking to JIRA and so on - following work like Jason is doing  
with Gerrit will be helpful to see how it goes.

> Maven site and documentation would benefit from easier forking/ 
> branching.
> Your project would benefit from using a tool that encouraged external
> innovation from non-committers and made it easier to merge radical
> contributions into the Maven documentation set.

Yes, these are the sorts of reasons it's worth investigating how we  
can use it to our advantage, for sure.

We do need to consider the flipside too though - I would guess that  
far fewer potential contributors will have a clue how to use git and  
it may actually hinder contributions. Simple documentation steps to  
follow that will probably suffice though - we had the same issue with  
the switch to SVN. It's still easy enough to create patches with git.

I think that's everything :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message