labs-labs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: Lab for distributed SCM?
Date Thu, 21 Feb 2008 17:03:21 GMT
On Feb 21, 2008, at 1:09 AM, Jukka Zitting wrote:
> The purpose of the lab wouldn't be to develop much software. A few
> scripts perhaps, but even they should probably be contributed
> upstream.
> By definition the Labs is a place for "innovative, blue-sky and
> off-the-wall ideas". Exploring dSCM options within Apache seems to fit
> that definition.

I don't think so.  Keep in mind that dSCM is not a new idea for the
folks who build support tools for open source.  It is just a fashionable
concept now because Linus's jump from bitkeeper reinvigorated a dozen
mostly-dead tools (in addition to creating git).

> Infrastructure would be the other place at Apache where this effort
> would be on-topic, but there are valid concerns about the openness of
> infrastructure@ (committers only, no easily browseable or searchable
> archives) and I fear that the task-oriented nature of Infrastructure
> is not very conductive for lab-like exploration.


> There are a number of purely technical advances that dSCM tools might
> well give us. Things like offline use, local revision comparisons,
> merge tracking, etc. are things that would IMHO be directly beneficial
> without requiring any changes to our development model. Whether and
> how such features could be achieved with Subversion (merge tracking in
> 1.5, svnsync) or perhaps with svn features of dSCM clients would be
> prime candidates for exploration by the proposed lab.
> Also, many companies are actively tracking Apache sources in vendor
> branches within their own SCM systems where they maintain
> customizations and other changes. Such work would be notably easier
> with dSCM tools. It's debatable whether we should assist people in
> doing that, and collecting related arguments to help build consensus
> on that would be a good task for the proposed lab. Interestingly the
> spirits of our licensing and development models point to different
> directions on this matter.
> More fundamentally, do the tools we use drive our development model or
> does the development model direct the way we use our tools? This is an
> open question and collecting real-world experience and different
> viewpoints would be quite valuable.

Not really.  Seriously, all of these are known facts, not things we
need to discover.  It is a known fact that centralized models require
deeper centralization of processes (agreement up front) and make it
much harder for folks maintaining independent forks.  In my opinion,
that is a good thing for Apache.  It is terrible for Linux.

> The dSCM issue is popping up in various forums again and again (the
> latest debate is not the first time we've seen it) and I think it's
> sad how even many of the good ideas in those discussions get drowned
> by the almost categorical "it's not the Apache Way" and
> "infrastructure won't support it" responses I'm seeing. A lab would
> provide a place where such ideas could be evaluated and the
> experiences documented. I'd be very happy if the lab would end up
> producing a dSCM FAQ for Apache.

Great, but still "it's not the Apache way" of developing software.
The problem with these discussions is that the folks who have
picked up on the latest dSCM hype from Linux projects think that
we haven't considered these issues at Apache before.  Sorry, we have.
It is not the tools that are the problem -- the problem is that new
developers don't want to collaborate the way we do at Apache because
it is much harder than each developer living in their own private
world, only sharing subsets of that world with the project, and
giving them the tools to make non-collaboration easier is not the
desired solution to that problem.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message