----- Original Message ----- > From: "Andrzej Oleś" <[email protected]> > To: "Dan Tenenbaum" <[email protected]> > Cc: [email protected], "Wolfgang Huber" <[email protected]> > Sent: Thursday, September 24, 2015 10:28:14 AM > Subject: Re: [Bioc-devel] Shouldn't we distinguish between package-specific > and dependency errors? > > > > > > Hi Dan, > > thank you for clarifying! I had this impression after looking at > > http://bioconductor.org/checkResults/devel/bioc-LATEST/flowcatchR/ > and > http://bioconductor.org/checkResults/devel/bioc-LATEST/GenomicInteractions/ > > which both produce errors during R CMD check, nevertheless, these > problematic versions are available on the corresponding package > landing pages. Probably that's because the package started failing > check only sometime after the update... >
Yes, that is probably what happened. Also, a maintainer can change a package without bumping the version number. In this case, even if the package builds and checks, it will not be propagated since there was no version bump. Dan > Best, > Andrzej > > > > On Thu, Sep 24, 2015 at 6:12 PM, Dan Tenenbaum < > [email protected] > wrote: > > > > > ----- Original Message ----- > > From: "Andrzej Oleś" < [email protected] > > > To: "Wolfgang Huber" < [email protected] > > > Cc: [email protected] > > Sent: Thursday, September 24, 2015 5:56:20 AM > > Subject: Re: [Bioc-devel] Shouldn't we distinguish between > > package-specific and dependency errors? > > > > Hi, > > > > we need to distinguish here between build/install and check errors. > > The > > first ones hold the package update (instead, the last working > > version > > is > > used). On the other hand, check errors do not hold the package from > > propagating into the repository causing collateral damage (at least > > that's > > what I observe in the devel branch). > > > > If a package does not pass R CMD check, it does not propagate into > the repository. > > Dan > > > > > > A good example is EBImage which is currently broken for all > > architectures > > but Linux (see: > > http://bioconductor.org/checkResults/devel/bioc-LATEST/EBImage/ ). > > It > > doesn't affect it's downstream dependencies because the error > > occurs > > at > > build stage, see for example imageHTS ( > > http://bioconductor.org/packages/3.2/bioc/html/imageHTS.html ). > > Fair > > enough, > > EBImage has a red badge, whereas imageHTS has a green one. > > > > So the issue raised by Ludwig occurs only with packages which fail > > during > > check. Maybe changing the publication policy in such cases, i.e. > > hold > > the > > updated package from going into the repository when it fails 'R CMD > > check' > > would help to address the problem, at least for BioC packages? > > > > Best, > > Andrzej > > > > On Thu, Sep 24, 2015 at 2:22 PM, Wolfgang Huber < [email protected] > > > wrote: > > > > > It seems that the “build” shield on the package landing page > > > conflates > > > things that happen in the package, and in its dependencies. > > > Do we have a clear spec of what the purpose of that shield is? > > > > > > Something to avoid IMHO is creating incentives for package > > > developers to > > > reduce dependencies to make their package “look" more robust, at > > > the cost > > > of duplication or functionality. > > > > > > Wolfgang > > > > > > > > > > On 24 Sep 2015, at 14:13, Ludwig Geistlinger < > > > [email protected] > wrote: > > > > > > > >> Do you have any information on how often this kind of breakage > > > >> occurs? > > > > > > > > Having my package ~1 year in, I would say that happened roughly > > > > 5 > > > > times > > > to > > > > me. > > > > > > > > I wonder whether other developers could comment on their > > > > experience with > > > > that as well. > > > > > > > > > > > >> On Thu, Sep 24, 2015 at 4:35 AM, Ludwig Geistlinger < > > > >> [email protected] > wrote: > > > >> > > > >>> Dear Bioc-Team, > > > >>> > > > >>> I would like to make this point brought up by Weijun more > > > >>> general. > > > >>> He reported a considerable number of packages to be broken by > > > >>> (recursively) depending on KEGGREST - which actually broke > > > >>> due > > > >>> to KEGG > > > >>> itself (however, this seems to be resolved by the current > > > >>> build). > > > >>> > > > >>> Nevertheless, given that a dependency can break your package > > > >>> at > > > >>> any > > > >>> time, > > > >>> it is currently hard to device a robust and stable software > > > >>> product > > > even > > > >>> within the semi-annual release. > > > >>> > > > >> > > > >> Do you have any information on how often this kind of breakage > > > >> occurs? > > > >> > > > >> > > > >>> Thus, I wonder whether Bioc packages in release (at least > > > >>> those > > > >>> having > > > >>> other packages depending on them) shouldn't always be rolled > > > >>> back to > > > the > > > >>> last version that passed build and check without error, in > > > >>> order to > > > >>> ensure > > > >>> functioning of packages down the hierarchy. > > > >>> > > > >>> Based on these considerations, I also wonder whether the > > > >>> shield > > > >>> on the > > > >>> package landing page indicating the result of the package > > > >>> building > > > >>> (ok/warning/error) shouldn't distinguish between errors > > > >>> caused > > > >>> by > > > >>> dependencies and errors caused by the package itself. > > > >>> > > > >>> Imagine the not too unrealistic case of a new Bioc package > > > >>> presented in > > > >>> a > > > >>> Software article under review. > > > >>> Without doubt, a reviewer will be negatively influenced by > > > >>> the > > > >>> 'error' > > > >>> shield indicating that the package has not been properly > > > >>> worked > > > >>> out. > > > >>> This is fair enough if the package's own code produces these > > > >>> bugs, but > > > >>> the > > > >>> opposite it true if that is due to a broken dependency. > > > >>> > > > >>> > > > >> Recent developments at the Volkswagen company should help > > > >> raise > > > >> general > > > >> awareness that software development and maintenance is a > > > >> fraught > > > process. > > > >> If > > > >> software S depends on software T and T is unreliable then so > > > >> is > > > >> S. The > > > >> negative influence of events of the sort you describe has > > > >> potential > > > value. > > > >> > > > >> I believe there are ways of using containers so that software > > > >> can be > > > >> distributed > > > >> in a verified working state, perhaps suitable for a fully > > > >> predictable > > > >> review, > > > >> but I doubt this is a real solution to the actual problem. > > > >> > > > >> > > > >> > > > >>> In the worst case, the package will run fine the whole time > > > >>> the > > > >>> article > > > >>> is > > > >>> prepared, but breaks due to a broken dependency the day the > > > >>> reviewer > > > >>> starts to evaluate the manuscript. > > > >>> > > > >>> I know that this does not resolves problems of dependencies > > > >>> outside of > > > >>> BioC such as for KEGGREST with KEGG. > > > >>> But at least for dependencies within BioC, I wonder whether > > > >>> this is a > > > >>> point worth considering. > > > >>> > > > >>> Thanks & Best, > > > >>> Ludwig > > > >>> > > > >>> > > > >>> -- > > > >>> Dipl.-Bioinf. Ludwig Geistlinger > > > >>> > > > >>> Lehr- und Forschungseinheit für Bioinformatik > > > >>> Institut für Informatik > > > >>> Ludwig-Maximilians-Universität München > > > >>> Amalienstrasse 17, 2. Stock, Büro A201 > > > >>> 80333 München > > > >>> > > > >>> Tel.: 089-2180-4067 > > > >>> eMail: [email protected] > > > >>> > > > >>> > > > >>>> Hi Weijun, > > > >>>> > > > >>>> ----- Original Message ----- > > > >>>>> From: "Luo Weijun" < [email protected] > > > > >>>>> To: [email protected] , [email protected] > > > >>>>> Cc: "Martin Morgan" < [email protected] >, > > > >>> [email protected] > > > >>>>> Sent: Wednesday, September 23, 2015 9:44:13 AM > > > >>>>> Subject: KEGG REST issue > > > >>>>> > > > >>>>> Dear BioC team, > > > >>>>> I noticed some problem with keggLink() function of KEGGREST > > > >>>>> package, > > > >>>>> and it can be traced back to KEGG REST API Linked entries. > > > >>>>> Some of > > > >>>>> this API function is broken. For example, the following > > > >>>>> line > > > >>>>> used to > > > >>>>> get all gene-pathway mapping for human, but retrieves > > > >>>>> nothing > > > >>>>> now. > > > >>>>> path.hsa= KEGGREST::keggLink("pathway", "hsa") > > > >>>>> > > > >>>>> In fact, these two bulk queries with the rest api > > > >>>>> don’t work > > > >>> anymore. > > > >>>>> http://rest.kegg.jp/link/pathway/hsa > > > >>>>> http://rest.kegg.jp/link/hsa/pathway > > > >>>>> but smaller queries on Linked entries seem to be fine. not > > > >>>>> sure > > > >>>>> whether other REST API functions are affected or not. As a > > > >>>>> consequence, KEGGREST and many dependent packages had build > > > >>>>> error. > > > >>>>> > > > >>> > > > http://bioconductor.org/checkResults/release/bioc-LATEST/KEGGREST/morelia-buildsrc.html > > > >>>>> > > > >>>>> anway, just want you know about this, see if you can do > > > >>>>> anything on > > > >>>>> this. > > > >>>> > > > >>>> Yes, I am aware of this. It's an issue on the KEGG side and > > > >>>> I > > > >>>> have > > > >>>> contacted the KEGG team. I have not heard back yet. > > > >>>> > > > >>>> Dan > > > >>>> > > > >>>> > > > >>>>> Weijun > > > >>>>> > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> [email protected] mailing list > > > >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > >>>> > > > >>> > > > >>> _______________________________________________ > > > >>> [email protected] mailing list > > > >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > >>> > > > >> > > > > > > > > > > > > -- > > > > Dipl.-Bioinf. Ludwig Geistlinger > > > > > > > > Lehr- und Forschungseinheit für Bioinformatik > > > > Institut für Informatik > > > > Ludwig-Maximilians-Universität München > > > > Amalienstrasse 17, 2. Stock, Büro A201 > > > > 80333 München > > > > > > > > Tel.: 089-2180-4067 > > > > eMail: [email protected] > > > > > > > > _______________________________________________ > > > > [email protected] mailing list > > > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > > > > _______________________________________________ > > > [email protected] mailing list > > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > > > > > [[alternative HTML version deleted]] > > > > > > _______________________________________________ > > [email protected] mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > > _______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
