Hi, On Wed, Feb 20, 2008 at 9:26 PM, Roy T. Fielding <[EMAIL PROTECTED]> wrote: > On Feb 20, 2008, at 4:13 AM, Jukka Zitting wrote: > > I think Apache Labs would be a perfect place for such work. > > Umm, why? The one thing that Labs doesn't do is "Apache-style > collaborative development."
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. 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. > I don't understand what the big deal is about. dSCM systems are > specifically designed to solve the problems of Linux-style development, > where each developer has their own working tree and they are only > vaguely working on a common problem. The "limitations" of the > centralized model are that people are forced onto common branches, > getting early agreement on large changes, and making decisions as > a group when there is disagreement. But those are Apache's strengths. I'm personally very much in agreement about our development practices and have for example used the very same argument recently in the incubating Apache River project. I'm not suggesting that we change our development model, just to explore ways in which different tools could support that. And I'm far away from saying that we should abandon Subversion, IMHO it would be perfect if we could consolidate ideas from the dSCM debate to well qualified feature requests to Subversion. 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. > In other words, I don't think experimentation (or documentation) > in Labs will do any good -- contributing to the documentation within > one or more dSCM projects is a far more useful activity. None of the tasks I outlined above are really specific to any given tool. They might well suggest places where additional tool documentation would do good, but that's IMHO not the primary goal. 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. BR, Jukka Zitting --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
