From ggrothendieck at gmail.com  Sat Sep 10 20:42:12 2005
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Sat, 10 Sep 2005 14:42:12 -0400
Subject: [Rd] Issue tracking in packages [was: Re: [R] change in
	read.spss, package foreign?]
In-Reply-To: <Pine.LNX.4.63a.0509100933520.17336@homer24.u.washington.edu>
References: <3.0.6.32.20050909015829.007bed60@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>
	<971536df05090910442796d89d@mail.gmail.com>
	<Pine.LNX.4.63a.0509091250220.5570@homer23.u.washington.edu>
	<17186.46037.468981.530188@mithrandir.hornik.net>
	<971536df050910055166ae0a14@mail.gmail.com>
	<971536df0509100602238abe70@mail.gmail.com>
	<Pine.LNX.4.63a.0509100933520.17336@homer24.u.washington.edu>
Message-ID: <971536df050910114251a8cce6@mail.gmail.com>

On 9/10/05, Thomas Lumley <tlumley at u.washington.edu> wrote:
> On Sat, 10 Sep 2005, Gabor Grothendieck wrote:
> >
> > 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).
> >
> 
> I don't see any advantage in symmetry.  The locations of these

The present discussion is where the change information may be located
but that is also true of the source and other information.    We could
just as easily have a field in the DESCRIPTION that tells the build
where to find the R source.
Its really the same issue.  

> subdirectories are fixed and I can't see why someone trying to decide
> whether to install an upgrade needs to know if it has an exec
> subdirectory before they download the package.
> 

That is a different issue which has not been discussed up to now.
I agree that that would be desirable.  It does seem independent
of the other issues discussed.  If CRAN processing speed can be
enhanced then I see no reason other than work involved to have the
build automatically enter a DESCRIPTION field of News: Yes
However, to make the user fill out another field and to burden
the user with having to look at DESCRIPTION first seems 
to add complexity without benefit.

I can think of one intermediate situation.  The source DESCRIPTION
has the path to the NEWS which the build grabs and puts it in
a standard place in the built package.  However, if we allow that for 
the NEWS then we should allow it for all components rather than
an inconsistent approach.

> I also don't see why THANKS and WISHLIST should need to be visible before
> you download the package.  CRAN does display a URL if one is given, and if

Either way would be ok in my opinion.

> these are important they could be at that URL.
> 
> The changelog, on the other hand, is one piece of information that is
> really valuable in deciding whether or not to update a package, so it
> would be worth having it visible on CRAN.  Since other coding standards
> suggest different things for the name and location of this file, a path in
> DESCRIPTION seems a minimal change.

There is no current standard. This is our chance to make it the same
for all packages and therefore easier for all users.


In short, how about we have a standard name and location for
the NEWS, cvs/svn log, WISHLIST, THANKS in the source
package.  The build would maintain their locations and, in
the case of NEWS and the svn/cvs log enter lines in the
DESCRIPTION file such as:

NEWS: Yes
ChangeLog: Yes

for sake of CRAN processing speed (if it turns out that
this does make a material difference which it may not).

This would seem to satisfy all requirements.  Its simple,
its easy to move to since one just renames or renames
and moves one's files (without the need for modifying the
DESCRIPTION file in every package or having yet more fields
in the DESCRIPTION file) and its easy for the 
user since they know where everything is supposed to be 
located without a complicating level of indirection.



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