----- Original Message ----
> From: Joe Schaefer <joe_schae...@yahoo.com>
> To: community@apache.org
> Sent: Wed, September 15, 2010 12:05:27 PM
> Subject: Re: "Forking is a Feature" reactions?
>
> ----- Original Message ----
>
> > From: Santiago Gala <santiago.g...@gmail.com>
> > To: community@apache.org
> > Sent: Wed, September 15, 2010 11:50:34 AM
> > Subject: Re: "Forking is a Feature" reactions?
> >
> > On Wed, Sep 15, 2010 at 5:23 PM, Joe Schaefer <joe_schae...@yahoo.com>
>wrote:
> > (...)
> > > 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.
> > >
> >
> > It is amazing how you (and I mean a big y'all of people negating
> > distributed SCM along those last 5 years or so) can keep the illusion
> > that a technical solution (called "centralization" here) can keep an
> > organization together more than a set of core values can.
>
> It comes from experience with dealing with younger projects in the
> Incubator that are not so enthralled with svn's workflows, and the
> social problems that seem to result from those attitudes. Eric is
> a relatively new committer at Apache and he still talks about his
> role as being like a "gatekeeper". That's not something he picked
> up from us.
To try to put my finger on the key distinction I've seen, a "centralized"
workflow puts demands on people to "make promises" up front. IOW before
you start that work on a snazzy new feature, you have to explain to people
what you're doing and why, and to set expectations for the final outcome.
That's because they will be exposed to your work whether they like it or
not, because it all gets thrown onto the commit list. IME it is a rare
human being that can follow through on a promise made to another over the
net. It's part of what makes Apache people so special ;-).
In a decentralized workflow you don't need to do that, in fact you can
keep your branch entirely to yourself and only reveal the work once it's
completed. If committers work this way from the get-go by using git-svn,
they tend not to look for such pre-agreements from each other, hoping for
review on the backend. And the idea that a big lump of code dcommitted
in rapid succession reveals the same amount of information as it would
have if the commits were subject to review in real time really doesn't
do justice to the whole concept of peer review, especially the lightweight
manual inspection of the commit messages. Yes you have all the tools to
make sense of everything save for one key aspect: the evolution of time.
And that lightweight evaluation that comes from reading and following up
to commit messages is really a big part of how Apache projects that are
operating well do function. Yes we can automate per-commit testing
with buildbot and hudson, but testing alone won't create a community
that places a paramount importance on constructive and timely peer review.
OTOH when non-committers take part in the review process, I really have no
concerns about the health of a project from an Apache standpoint, git usage
notwithstanding.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org
