Justin Erenkrantz <justin@erenkrantz.com> writes:
> 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!") --
I don't see what the last part has to do with anything. We reject
patches all the time, on the grounds that we don't want to maintain
the extra complexity in Subversion. In fact, I believe rejection (of
a patch or of a proposed patch) is far more common than acceptance.
I don't agree with this proposed mission for dist.sh. I feel it is
unclear and gives us no guidance about how to maintain the script. I
already said why in detail in my last mail, so I won't repeat that
here.
So: two people disagree somewhat about what dist.sh should do. That's
fine. Let's hear what others have to say. It may be that a clear
consensus emerges. If not, well, we can cross that bridge when we
come to it.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 15:30:03 2005