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.
Yes.
...
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.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
