From ggrothendieck at gmail.com  Fri Sep  9 19:44:00 2005
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Fri, 9 Sep 2005 13:44:00 -0400
Subject: [Rd] Issue tracking in packages [was: Re: [R] change in
	read.spss, package foreign?]
In-Reply-To: <Pine.LNX.4.63a.0509091029550.5570@homer23.u.washington.edu>
References: <3.0.6.32.20050909015829.007bed60@pop.gmx.net>
	<3.0.6.32.20050909145010.007c2a70@pop.gmx.net>
	<Pine.LNX.4.63a.0509090845050.619@homer23.u.washington.edu>
	<971536df05090910211d639ed1@mail.gmail.com>
	<Pine.LNX.4.63a.0509091029550.5570@homer23.u.washington.edu>
Message-ID: <971536df05090910442796d89d@mail.gmail.com>

On 9/9/05, Thomas Lumley <tlumley at u.washington.edu> wrote:
> On Fri, 9 Sep 2005, Gabor Grothendieck wrote:
> >
> > I personally put NEWS, WISHLIST and THANKS files in the 'inst'
> > directory of all my source packages.  This has the effect of copying them to the
> > top level of the built version so that they are accessible from R via:
> >
> 
> I'm not sure that WISHLIST and THANKS need to be available to people who
> haven't installed the package.   NEWS, on the other hand, really does.
> 
> One option (if it doesn't turn out to be too much work for the CRAN
> maintainers) would be to have an optional Changelog field in the
> DESCRIPTION file giving the relative path to the file. This would mean
> that maintainers would not all have to switch to the same format.
> eg for foreign
>   Changelog: ChangeLog
> and for survey
>   Changelog: inst/NEWS
> 
> This might be enough to make it easy for CRAN to display these when the
> maintainer provides them.

How about if there were just a standard location and name such as inst/NEWS,
inst/WISHLIST, inst/THANKS (which has the advantage that they are automatically
made available in the built package under the current way packages are
built) and
then CRAN could just check if its there or not -- no need to change
and document
the DESCRIPTION file.  The only thing package developers who want to provide
these have to do is to use the indicated names and location.  It would still be 
possible as step 2 to provide your idea since its upwardly compatible.  

In fact, even with no software at all there would be an advantage to this since
users would definitively know where to look and would not have to download
the source package just to read this.



[Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
Gabor Grothendieck