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.
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
worlds?
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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
