On 10/05/2015 05:45 PM, Dan Tenenbaum wrote:
I'm not sure I like that idea, because then we are propagating packages that do
not build and/or check (even though there's a big fat warning when you load
them).
Right but if the package was passing build and check, there wouldn't be
much reason to deprecate it in the first place.
Also I don't like the idea of modifying the build system so close to the
release, and I don't have a lot of time to do that. We could look into doing it
after the release if it's decided to do this.
Agreed. Not a change you want to do now. The change to the build system
is too big to make it 1 week before a release.
H.
Dan
----- Original Message -----
From: "Hervé Pagès" <hpa...@fredhutch.org>
To: "Dan Tenenbaum" <dtene...@fredhutch.org>
Cc: "bioc-devel" <bioc-devel@r-project.org>
Sent: Monday, October 5, 2015 4:57:38 PM
Subject: Re: zzz.R in GenoView
Hi Dan,
What about modifying the build system to propagate deprecated
packages
that install? That also means that the build system should also be
modified to always perform the INSTALL step for a deprecated package.
H.
On 10/05/2015 03:31 PM, Dan Tenenbaum wrote:
Yes, this is part of a larger problem we need to think about.
I marked several packages as deprecated. In each case, the package
has not built successfully (and propagated) in some time. So the
deprecation message will not propagate to the end user, and the
special landing page text will not be present (if the web site
code sees "PackageStatus: Deprecated" in a DESCRIPTION file it
will add some special text to the landing page, saying the package
is deprecated, with further instructions, but again that only
shows up if the package builds succesfully).
Most of the time when we mark a package as deprecated we are doing
it because it does not build (and we can't reach the maintainer).
So there is this paradox that the deprecation warning we insert
will rarely be seen by end users.
This seems to be at odds with the intent of what we are trying to
do.
So instead what will happen when the end user tries to install one
of these packages (now or after the release) is:
- if the package did not build at all during the release cycle (or
if we flushed our
internal repos, a normal step leading up to release), biocLite()
won't find it
- if it did build during the release cycle, the last good build
will be installed, and will
not show the deprecation warning
Maybe this is all ok. In the rare case where a package still builds
but we decide to mark it as deprecated for another reason, the
warning will be seen as intended.
FYI
Dan
PS. Hervé, I fixed the Collate field for GenoView.
----- Original Message -----
From: "Hervé Pagès" <hpa...@fredhutch.org>
To: "Dan Tenenbaum" <dtene...@fredhutch.org>
Sent: Monday, October 5, 2015 3:21:27 PM
Subject: zzz.R in GenoView
FYI
http://bioconductor.org/checkResults/3.2/bioc-LATEST/GenoView/linux1.bioconductor.org-buildsrc.html
Looks like zzz.R needs to be added to the Collate field.
That will still not make the new version propagate though (because
its
vignette is broken, I think) so something else would need to be
done
if
we want the Deprecation message to reach the end user and/or the
package
landing page.
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
