Re: "Forking is a Feature" reactions?

----- Original Message ----

> From: Eric Evans <[email protected]>
> To: [email protected]
> Sent: Wed, September 15, 2010 11:13:15 AM
> Subject: Re: "Forking is a Feature" reactions?
> 
> On Wed, 2010-09-15 at 07:32 -0700, Joe Schaefer wrote:
> > > With a   centralized vcs, a select group of privileged individuals
> > > are given  access, they are the gate keepers.
> > 
> > Eh, no.  That's exactly  how Linux works, with people having protective
> > attitudes towards their  own trees: git only makes that mode of working
> > easier.  Here a  committer's job is to *facilitate* inclusive work, not
> > prevent  it.
> 
> I don't think the Linux work-flow is a particularly good example  for
> anything other than Linux.  The problem set certainly doesn't map  well
> to any of the projects I work on.
> 
> > > Everyone else gets a  "working copy" and is  expected to create a 
> > > patch (or  patches) and then work to convince a committer to apply 
> > >  them.
> > 
> > That's not the Apache model, fwiw.  Collaboration  means you work as
> > equals, committer status or not.
> 
> I agree with  the sentiment, but the choice of distributed vs.
> centralized vcs is a  technical one.  You can be as open and inclusive
> with contributors as  you want, without commit access they're relegated
> to a second-class  work-flow.

I can appreciate that, but the stock answer to that is "just give them
commit".  High barriers to committership is not what Apache is about.

> 
> > > A distributed version control system is a measure  toward  
> > > eliminating that have/have not distinction; it  reduces the barrier 
> > > to contribution.
> > 
> > No it  doesn't.  The learning curve alone is a barrier to its adoption.
> > It  just means you have the same access to the history as anyone else,
> > and  can develop on branches with far greater ease.  Github is the
> > great  new thing here, not git itself.  If github were open source we'd
> >  probably be using it at Apache already in some form.
> 
> I disagree, Github  adds a lot of value, but I'm thinking in terms of the
> differences between  distributed vs. centralized systems. The argument is
> the same with or without  Github, and could likewise include Mercurial,
> Bazaar, etc.
> 
> > >  Instead of a working copy you get a full working  repository.
> > >  Contributors can have long running branches where they work on  
> >  > large features while easily keeping in sync with upstream
> > >  changes. And when the contributor repos are public, others can 
> > >  follow their progress and provide feedback and collaborate.
> > > 
> > > If useful changesets that are  languishing in random  repositories 
> > > and are not making it upstream, that is a   social problem, not a 
> > > technical one.
> > 
> > Yes, but  that just begs the point: this thread is about the social
> > implications  of the choice of vc tool, and the aforementioned author
> > of the blog post  seems to think forking in all its forms is a good
> > idea for societies.  Somehow I doubt that's the case. 
> 
> It doesn't frighten me.

It does give me pause because I believe there's an important role for a
set of central services for projects (and for societies in general).  As
far as Apache goes, it's a virtual organization whose roots lie in the
stuff we have stored in various datacenters.  Nevertheless there is a
palpable sense of what it means to "do work at Apache", and part of that
illusion is provided by our centralization.  I do wonder how we'd manage
to maintain that illusion if we completely decentralized our core workflows.