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:
https://grid.sonatype.org/ci/view/Maven%203.0.x/job/maven-3.0.x-ITs/
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: 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
----------------------------------------------------------
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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
