"Sander Striker" <striker@apache.org> writes:
> Because that would mean we support one client effort over another
> by having it in the standard distribution. That wouldn't be fair
> to the projects that aren't in the svn repos.
>
> We discussed this quickly on irc yesterday and forgot to post the
> conclusions. We == gstein, sussman, xela, me and others.
Er, okay, but...
This still doesn't make much sense to me.
Projects that "aren't in the svn repos" are neither in
/trunk/subversion/clients/ nor in /clients -- they're in whatever
repos their author keeps them in. So if we've been disfavoring
certain clients by having them outside the repos (a questionable
assertion, since it was more likely the client author's choice than
ours), we're *still* disfavoring those clients, because this
rearrangement does nothing to bring them into the repos.
If a client is in our repos at all, I see no problem having it in
trunk, such that it's in the standard distribution. If the thing
builds, then great. If not, then it just doesn't get built as part of
the standard build process. If something's not ready for prime time,
the documentation can just say so.
If our goal is to solve the endorsement problem, by deciding to
endorse nothing, then this is not a solution. If having something in
our repository at all implies endorsement, then we're *still*
endorsing these clients under this new arrangement. And if having
something in our repos does not imply endorsement, then we might as
well keep them in /trunk/.../.
If we just want to provide generic repository hosting services for
people writing SVN clients, then that's wonderful, but shouldn't it be
a different physical repository? (Perhaps even one repository per
client, but at the very least a different repos with a separate auth
structure?)
I'm not adamantly opposed to the new arrangement to the point of
vetoing it or anything like that. But I don't understand the point --
it doesn't seem to serve its goals very well. I think it's just going
to be confusing. Heck, I'm already confused, as you can tell :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 26 22:08:17 2002