labs-labs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Lab for distributed SCM?
Date Sat, 23 Feb 2008 00:19:00 GMT
Paul Querna wrote:
> Stefano Mazzocchi wrote:
>> Paul Querna wrote:
>>> Stefano Mazzocchi wrote:
>>>> Paul Querna wrote:
>>> Quoting from Roy's proposal:
>>> <>

>>> ====
>>> This is, essentially, a documentation project consisting of a group
>>> of editors' sandboxes under version control.  There are no releases
>>> and most discussion, if any, will be on other organizations' lists
>>> (aside from the chatter among the committers working on the lab itself).
>>> A public version history is extremely important for this kind of work
>>> in order to combat attempts to monopolize certain standards after the
>>> ideas have been published.
>>> =====
>>> It's very clear, he is doing a documentation project related to 
>>> existing Apache projects, which there are several examples of working 
>>> well inside Apache.
>> I fail to see how documenting ideas about possible improvements to 
>> HTTP is pertinent to Labs while documenting ideas about improvements 
>> to version control is not. Subversion might not be an apache project, 
>> but it's clearly a central piece of our infrastructure and its 
>> features drive (and were driven from) a lot of our own social dynamics.
> Ah, but that is the point -- If the documentation was about using our 
> shared infrastructure, then there already is a place for that: site-dev.
> That list is responsible for managing the documentation on 
> infrastructure, and how we use it at:
>  <>
> If the goal is to produce documentation on how to use git-svn for 
> example with the Apache SVN repository, I believe the correct place for 
> such a project is on site-dev, not the Labs.
> Stefano Mazzocchi wrote:
>> Just so that I understand better where your negative vote comes from: 
>> are you afraid that lack of code is going to generate ungrounded and 
>> hard to resolve discussions (while in Roy's case, it was really his 
>> own lab with his own ideas and hardly people would challenge him at 
>> this draft stage) or is it something else I'm missing?
> I do believe that documentation can be a valid project, but I also 
> believe that documentation related to infrastructure already has a home, 
> and Labs is not it.
> If the Lab proposal is not about documentation, then what is it?
> When you remove documentation, what is left from the original proposal, is:
> """Most importantly it would provide a neutral ground for discussing the 
> merits of different systems and practices. """
> Which has been mentioned already by others[1] on this list as not making 
> sense for Labs.  As I said in my first mail, I do not believe that this 
> is the place to have a neutral ground for discussing.
> If there is another significant purpose of this proposed lab, please 
> tell me.
> But based on the original proposal, I believe that there isn't a need 
> for a Lab.

Paul, thanks for expressing your concerns clearly, it does indeed help 
in evaluating the situation better.

Even after your well thought-out points, I still find myself thinking 
that collecting information, solutions, state-of-the-art and general 
practices about the difference between centralized version control and 
distributed is not as simple as 'paving the cowpath' and document it its 
location, but it requires a certain dose of 'research' and collaborative 

For example, Roy has already indicated that he believes that central vs. 
distributed is nothing but a reflection of social dynamics and that 
constraints imposed by the tools are in fact a feature and not a bug. My 
interpretation of Linus's position on the subject feels parallel to 
Roy's in rejecting the other side as suboptimal for the social practices 
established in the different communities.

Understanding the impact of such assumptions is *far* from paving the 
cowpath, if you ask me.

I don't claim to know what the solution is or whether Roy or Linus are 
right, but stating that subversion's current feature set is 'complete' 
as in 'best possible for the apache-style development dynamics' might be 
true, but needs research and brainstorming for me to buy it (for 
example, svn lacks git's binary backtracking, which has nothing to do 
with central vs. distributed, but in order to be implemented, it might 
require more local and offline storage abilities... which might lead to 
a better offline behavior for svn as well)

Once participating on the JCR expert group, I was shocked to hear the 
guys who designed DeltaV (the versioning extension to WebDAV that svn 
partially implements) to admit that they were not familiar with (aka 
never used) CVS. My attempt to bring them up to speed with it resulted 
in a rather close-minded and disappointing discussions, mostly related 
to the fact that their feature set was bigger than CVS and therefore it 
was moot to discuss something that was inferior/less-capable. I'm not 
suggesting anybody is doing the same here, but I do believe it's always 
healthy to evaluate alternative approaches without fear and with an open 

Personally, i think that believing that svn or git's feature set is 
'complete' and that one cannot learn from the other feels as a potential 
threat to our ability to innovate, adapt and evolve.

And labs were created exactly to foster innovation thru constructive 
discussions and avoid the process/inertia-induced stagnation.

But understanding whether or not a particular feature is good or bad and 
for what dynamics, requires substantial argumentation, research, 
discussion and even brainstorming, on how to dissect the issue and get 
to the core of the problem.

Hardly such a process can be described as a simple documentation one, at 
least in my experience.

It is true that, ultimately, labs might not be the place for such 
verbose discussions (as it might consume too much oxygen on this mail 
list and remove it from other things), but, if you ask me, I'd rather 
risk that than having a good research idea die because of lack of 
nurturing support.


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

View raw message