From ggrothendieck at gmail.com  Fri Sep  9 19:21:41 2005
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Fri, 9 Sep 2005 13:21:41 -0400
Subject: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss,
	package foreign?]
In-Reply-To: <Pine.LNX.4.63a.0509090845050.619@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>
Message-ID: <971536df05090910211d639ed1@mail.gmail.com>

On 9/9/05, Thomas Lumley <tlumley at u.washington.edu> wrote:
> 
> Many packages have a NEWS or ChangeLog file describing changes.  You would
> typically have to look at the source package to find them, since by Unix
> tradition they are usually in the top-level directory and so are not
> included in the binary build.
> 
> The foreign package is on svn.r-project.org, so you can see its Changelog
> there. There have been suggestions to extract these files and put them in
> the CRAN listing, but one obstacle is the lack of standardisation.

Of course this has been discussed a number of times but since its being
brought up again let me just add that there is a substantial need for something
here (i.e. something to address the lack of a standard way of communicating 
issues in packages including changes, outstanding bugs, wishlist items, etc.)  

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:

   system.file("NEWS", package = "mypackage"))

without the burden of having the user retrieve the source and I think we 
need something like that, in general.

If someone wanted to set it up it would really be nice to have sourceforge-like
facilities made available for package developers providing groupware
facilities such as svn for each package, Trac issue tracking for each package, 
home page for each package, email list for each package, etc.  Its probably
too much ongoing work to provide this on a package by package basis but 
an automated system that made it easy for package developers to access this 
all in a standard way on a self-serve basis similar to OpenSVN would
be feasible
if someone wanted to do it.



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