You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Shane Curcuru <as...@shanecurcuru.org> on 2008/02/07 17:28:50 UTC

Re: [PROPOSAL] Thrift]

community-digest-help@apache.org wrote:
> "Santiago Gala" <sg...@apache.org> wrote:
> On Feb 2, 2008 2:48 PM, Leo Simons <ma...@leosimons.com> wrote:
>> On Feb 2, 2008, at 1:20 AM, David Reiss wrote:
>>> J Aaron Farr wrote:
snip...
>> 1. You have to use subversion.
>>
> 
> Why? Has been a vote done? where? I vote +1 for git if a vote is still open.

In the short term, the reason is because Infra doesn't yet support it, 
and ASF projects need to be hosted at the ASF.  That's not to say we 
shouldn't see if there are enough existing ASF committers who'd like 
to use git for ASF projects, and if so, try to get Infra to support 
it.  Even though we do have (some) paid infra staff, it's still not an 
easy thing to deploy a completely new tool.

In the medium term, I'd like to see a broader desire to use git, along 
with some thoughts as to why new projects need it instead of svn.  I 
definitely understand your comments about infra needing to support 
projects.  But I also don't think the ASF should try to be all things 
to all projects.  I'd like to see how git users run projects 
differently than svn users, and make sure that it really fits with how 
we (the ASF) like to have consensus based community projects.

git feels like a different enough way to manage the core resource of 
any project - the code (and/or docs, test, build, etc.) that I'd like 
to put some thought into having us support it, rather than just 
jumping in - both on the infra side (scalable repository; admin 
expertise), legal side (how to we track all incoming changes?) and the 
community side (are they close to The Mythical Apache Way?).  If that 
means some community that's in a huge hurry wants to go build their 
project elsewhere, that's OK with me.  You can call me an elephant 
sometimes, too.  8-)

- Shane

Re: [PROPOSAL] Thrift]

Posted by Kevin Menard <km...@servprise.com>.
On 2/7/08 11:28 AM, "Shane Curcuru" <as...@shanecurcuru.org> wrote:

> In the medium term, I'd like to see a broader desire to use git, along
> with some thoughts as to why new projects need it instead of svn.  I
> definitely understand your comments about infra needing to support
> projects.  But I also don't think the ASF should try to be all things
> to all projects.  I'd like to see how git users run projects
> differently than svn users, and make sure that it really fits with how
> we (the ASF) like to have consensus based community projects.

I wasn't involved in the original thread at all, but wanted to chime in.  It
seems to me that while git is the tool in question, it's really a matter of
a distributed versus centralized model.  That, unfortunately, heads down the
road of religious debate.

I happen to like Subversion a lot.  It has excellent tool support, is pretty
straightforward to admin, and does its job well.  However, it can be quite a
turn-off for attracting new committers.  It's like we're saying "you can
contribute, but you can't use a reasonable tool to do it."  In the past, to
get around this I would mirror the SVN repository with some other tool, such
as tailor, for some other SCM, such as darcs.  Clearly, this is a less than
ideal situation. 

> git feels like a different enough way to manage the core resource of
> any project - the code (and/or docs, test, build, etc.) that I'd like
> to put some thought into having us support it, rather than just
> jumping in - both on the infra side (scalable repository; admin
> expertise), legal side (how to we track all incoming changes?) and the
> community side (are they close to The Mythical Apache Way?).  If that
> means some community that's in a huge hurry wants to go build their
> project elsewhere, that's OK with me.  You can call me an elephant
> sometimes, too.  8-)

I don't know enough about git to comment reliably here, but most of the
distributed SCMs I've come across have the concept of a pristine, master
copy.  This copy can be configured such that only certain people can push
changes to it.  All others would have to submit patches through to the one
of these people or via some other channel, such as JIRA.  So, while the
implementation is slightly different, it seems to model the existing
structure fairly well.

-- 
Kevin


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org