Re: [Bioc-devel] zzz.R in GenoView
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" To: "Dan Tenenbaum" Cc: "bioc-devel" 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" To: "Dan Tenenbaum" 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
Re: [Bioc-devel] zzz.R in GenoView
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 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" > > To: "Dan Tenenbaum" > > Cc: "bioc-devel" > > 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" > > >> To: "Dan Tenenbaum" > > >> 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
Re: [Bioc-devel] zzz.R in GenoView
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" > To: "Dan Tenenbaum" > Cc: "bioc-devel" > 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" > >> To: "Dan Tenenbaum" > >> 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
Re: [Bioc-devel] 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" To: "Dan Tenenbaum" 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
Re: [Bioc-devel] zzz.R in GenoView
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" > To: "Dan Tenenbaum" > 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. > ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
