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?
Therefore, I prefer the first answer. I think we should consider
dist.sh to be the tool we use to roll our own releases, nothing more.
When we originally wrote it, we never envisioned it taking on any more
burden than that. Why would we try to expand its mission now? I feel
like the compelling use cases and examples just aren't there. Sure, a
few people have done it from time to time, but people do lots of
things that the Subversion project doesn't provide direct support for.
In the long run, it'll be much easier to maintain dist.sh if it has a
narrow, clear mission.
That's my $0.02. Justin, if I'm missing any important parts of the
argument you're making, sorry & please correct.
Thanks,
-Karl
Justin Erenkrantz <justin@erenkrantz.com> writes:
> --On Saturday, April 2, 2005 4:26 PM -0800 Ben Reser <ben@reser.org> wrote:
>
> > a) This is a feature... When we add features we have to way the
> > benefits, costs, and if it's even really useful. We have tried to shy
> > away from implementing features that are highly specialized to a
> > particlar group of people or that nobody has really ever asked for or
> > can come up with a use case for.
> >
> > Granted, I know of some use cases for this, but they are rare. I can
> > think of all of 4 people that I'm aware of that have ever run dist.sh
> > recently. And none of them have ever had a problem getting
> > dependencies.
>
> Might not their jobs be easier if there was another way? I'd would
> like to reduce the complexity required by the person running the
> dist.sh script to make it easier to roll a tarball (be it for random
> use or for public distribution).
>
> > b) We also have to look at the alternatives to the feature. What could
> > we do that might be better.
>
> The 'svn export' is a solution that allows the dependencies to bundle
> the dependencies without having them downloaded previously. To be
> clear, in IRC on Friday, I had suggested that dist.sh have the option
> to fetch the release tarballs from the site and allow the RM to
> confirm the dependency signatures manually before proceeding. But,
> you said that you would veto that as well even if I wrote that
> functionality.
>
> > I still think if we want to make it easier to produce a quick snapshot
> > tarball we make dist.sh capable of simply ignoring the depencies. Our
> > build system has no problem with this and it would be insanely simple to
> > do in dist.sh
>
> Yes, I agree that could be goodness as well. (i.e. -nodeps flag to dist.sh?)
>
> > c) We have to look at the drawbacks. In this particular case the vast
> > majority of the use of it is to produce our own tarball. If this
> > feature is used to produce the tarball it could be really bad. I'm not
> > going to harp on why again.
>
> And, as I've said, I don't think that's a major issue.
>
> > Wouldn't it lessen the overhead even more just by removing the need to
> > include the dependencies? We include them to lessen the burden on our
> > users downloading the tarball. But as far as I know most of the use
> > cases of dist.sh outside of our uses don't care about these dependencies
> > and only deal with them because dist.sh requires them.
>
> In the cases where I was creating snapshots, I was creating them for
> folks who didn't have the dependencies either (i.e. an OS with just a
> compiler that needed some SVN patches that weren't in a SVN release
> just yet). -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 07:12:18 2005