If it is total failure, we could consider having an empty package just saying does not work or something when loaded. Not sure that is great, but at least it tells people the problem.
If you put on the release hat, the package shouldn't get released if we know it doesn't work. It is preferable to deprecate it slowly, but sometimes people abandon stuff and there is a limit to what the project can support. Kasper On Mon, Oct 5, 2015 at 8:45 PM, Dan Tenenbaum <dtene...@fredhutch.org> 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). > > 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. > > 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 > > > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel