maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Using GIT as the canonical repository for Maven 3.x
Date Fri, 24 Apr 2009 03:47:45 GMT

On 23-Apr-09, at 6:17 PM, Brett Porter wrote:

> 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 today.
> 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.

As I stated before there is not a single new feature going in to the  
code until this refactoring is done. It's really not that exciting but  
the bootstrap feeds into this:

Which is an up-to-date accurate picture of where we stand.

If people want the occasional summary then ask. I'm fine doing that.  
But I think my attempt at the high level overviews like the recording  
at the meet up are far more effective then anything else. And the  
uptake from the blogs and videos are more useful to the community in  
general. If developers here were truly interested they would ask and  
I'm always happy to answer specific questions.

> I know you genuinely want other people involved in the long run.

It simply will not happen until this first round is done. After that,  
there will be lots of discussion because that will be the point at  
which new features can be added.

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

Anything is ASF hardware upon the decision of Apache Infrastructure.  
Here there I don't care to be honest. I feel the Apache hardware  
argument to be dogma at this point. Whatever is well maintained, safe,  
has a back strategy and accessible by infrastructure staff should be  
acceptable. I'm not interested in the eternal debate and there really  
is no debate when the instantaneous answers to requests is no.

> 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 worlds?

You cannot pull from multiple sources and then commit the aggregate  
without the commits getting all interleaved. For one person  
interacting it's fine. Hook Gerrit to marshall community contributions  
and it would be a mess as the Github folks answered today when I asked.

>> 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  
> forum.
> 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 :)
> Thanks,
> Brett
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

What matters is not ideas, but the people who have them. Good people  
can fix bad ideas, but good ideas can't save bad people.

  -- Paul Graham

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

View raw message