--On Saturday, April 2, 2005 10:46 PM -0600 kfogel@collab.net wrote:
> Okay, it sounds like we're homing in on the central question here:
>
> "What and who is dist.sh for?"
>
> If the answer is "It's for us to produce our releases with", then the
> export changes probably don't belong in it.
>
> If the answer is "It's for anyone who wants to roll some sort of
> Subversion release" (or something like that), then the export features
> start to make sense, and possibly so do a lot of other things. In
> fact, it becomes difficult to know what features we can leave *out*!
> After all, we know what it means for us to roll our own releases --
> that's a well-understood task. But we don't really know what other
> groups might be up to in rolling specialized releases of their own.
> How could we ever judge dist.sh's feature set or interface with any
> confidence, if go down this road?
I feel that dist.sh is a 'canonical' way for *anyone* to roll a Subversion
tarball. dist.sh should encapsulate any knowledge that we have to create a
'proper' Subversion tarball.
The only thing that makes our 'public' tarball special is that we decide to
call it 'Subversion' - anyone else can still roll a tarball, but they just
can't call it Subversion. What they do (or don't do) with it is their concern.
Therefore, we should be willing to accept patches (and/or commits) that don't
compromise or conflict with dist.sh for our internal purposes. This is what I
would expect for any file under our purview. ("You want to add some new
functionality? Submit your patches!") -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 09:31:51 2005