Paul Querna wrote:
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.
+1 to this conclusion; site-dev exists and is more appropriate.
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.
+1 to this conclusion; for example, infrastructure. Although I think that
both sides have presented their arguments, and if there is a desire to
simply find a "quiet home" where everyone just agrees that dSCM is the
hammer for all (many | some) of our nails, labs also isn't it.
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.
Agreed, and -1 as presented to this lab proposal. But that said, please
elaborate on what aspect would be uniquely suited to labs?
Although I'm pained by the difficulty mirroring/forking ASF code into some
private repository, that would be my issue, not the ASF's - isn't it? And
I've already expressed my opinion that the very purpose for dSCM doesn't
mesh with the purposes of collaborative development, but I have no trouble
with several checkouts mirroring several patches I plan to commit, and the
local checkouts of svn help me identify what's locally in-progress without
a round trip back to the server.
Could it be more? Sure, but the very nature of allowing a large number of
remote checkins, queued up and dumped on a project all at once, almost
certainly ensures that the flood will enjoy less oversite and scrutiny
than individual patches would enjoy. Personally I'm able to overwhelm
most conscientious httpd or apr code reviewers with just a few days of
effort, and shudder to think what would happen if I queued up all of that
for just a week or two, inflicting it all upon them at once.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
