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

Gabor Grothendieck ggrothendieck at gmail.com
Sat Sep 10 15:02:55 CEST 2005


On 9/10/05, Gabor Grothendieck <ggrothendieck at gmail.com> wrote:
> On 9/10/05, Kurt Hornik <Kurt.Hornik at wu-wien.ac.at> wrote:
> > >>>>> Thomas Lumley writes:
> >
> > > On Fri, 9 Sep 2005, Gabor Grothendieck wrote:
> > >> 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)
> >
> > > The problem is that there *isn't* a standard location. As Robert
> > > Gentleman has pointed out, if you only maintain two or three packages
> > > it isn't too bad to change them to some new layout, but if you are the
> > > bioconductor project it gets painful quite quickly.
> >
> > > Also, there are good reasons for having NEWS in the top level
> > > directory.  Nearly everything that isn't an R package does this,
> > > because it's a useful standard.
> >
> > And similar things could be said about Emacs users with ChangeLog files
> > in top-level package directories ...
> >
> > I like the suggestion about using a Changelog (or whatever it would be
> > called) field in the package DESCRIPTION meta-data.  If we have that, we
> > could not only use this for repository-side presentation of the package,
> > but also install such info and have a simple show_package_change_log()
> > function ...
> 
> One could have that without this meta data.  show_package_change_log
> could just check if the file is present.
> 

And one more comment.   The DESCRIPTION file does not record the
location or existence of the various subdirectories such as R, man, 
exec, etc. If NEWS is to be recorded as a meta data line item in 
DESCRIPTION then surely all of these should be too so its symmetric
and they are all on an equal footing (or else none of them
should be, which in fact I think is preferable).



More information about the R-devel mailing list