Norman,
> >> So what is the argument against SST going in as a software item in
> >> its own
> >> right? I mean, why should SST be treated differently to (say) AST?
> >
> > We're never going to distribute it outside the project?
>
> That's right -- undistributed and unsupported. Though since part of
> the motivation for the whole CVS transition is to cope with the
> situation where _everything_ is unsupported, the distinction is
> arguably fragile.
Does hiving off such items into a separate tree buy us anything?
> In any case, there needs to be some place for autoconf macros.
What about an "autoconf/" tree?
> Hmm, I think /cvs/devsupport would be better than /cvs/support, since
> it's probably less misunderstandable by the repository-browsing hordes.
It's just that both titles just sound a bit vague to me. What about items
(such as SST) which are often used as support for a package, but which
*can* be used independantly in its own right? Is it possible to have tree
names which indicate more explicitly what they contain (even if it means
having more than 1 tree)?
Speaking here of course as a seasoned and experienced CVS user...
David
----------------------------------------------------------------------
Dr David S. Berry ([log in to unmask])
STARLINK project | Centre for Astrophysics
(http://www.starlink.ac.uk/) | University of Central Lancashire
Rutherford Appleton Laboratory | PRESTON
DIDCOT | United Kingdom
United Kingdom | PR1 2HE
OX11 0QX
|