----- 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
