
   Well, I guess, Dan, that basically means that breaking cannot happen within
   Bioc (as broken packages do not propagate to the repository) and such cases
   are exclusively due to breaking of external dependencies such as observed
   with KEGGREST and KEGG (where we can hardly do much about it).

   Thus, it remains to clarify on the purpose of the ‚build‘ shield as Wolfgang
   pointed out.

   While it is surely helpful for the developer to grasp what is going on at a
   glance,  this might be misleading for users and reviewers as described
   earlier.

   Ludwig

   Am 24.09.2015 um 19:31 schrieb Dan Tenenbaum <[1]dtenenba@fredhutch.org>:

   ----- Original Message -----

     From: "Andrzej Oleś" <[2]andrzej.oles@gmail.com>
     To: "Dan Tenenbaum" <[3]dtenenba@fredhutch.org>
     Cc: [4]bioc-devel@r-project.org, "Wolfgang Huber" <[5]whuber@embl.de>
     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
     [6]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 <
     [7]dtenenba@fredhutch.org > wrote:
     ----- Original Message -----

     From: "Andrzej Oleś" < [8]andrzej.oles@gmail.com >
     To: "Wolfgang Huber" < [9]whuber@embl.de >
     Cc: [10]bioc-devel@r-project.org
     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:
     [11]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 (
     [12]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 < [13]whuber@embl.de >
     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 <

     [14]Ludwig.Geistlinger@bio.ifi.lmu.de > 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 <
     [15]Ludwig.Geistlinger@bio.ifi.lmu.de > 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: [16]Ludwig.Geistlinger@bio.ifi.lmu.de

     Hi Weijun,
     ----- Original Message -----

     From: "Luo Weijun" < [17]luo_weijun@yahoo.com >
     To: [18]maintainer@bioconductor.org , [19]dtenenba@fredhutch.org
     Cc: "Martin Morgan" < [20]mtmorgan@fredhutch.org >,

     [21]Bioc-devel@r-project.org

     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.

     [22]http://bioconductor.org/checkResults/release/bioc-LATEST/KEGGREST/more
     lia-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

     _______________________________________________
     Bioc-devel@r-project.org mailing list
     https://stat.ethz.ch/mailman/listinfo/bioc-devel

     _______________________________________________
     Bioc-devel@r-project.org 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: Ludwig.Geistlinger@bio.ifi.lmu.de
     _______________________________________________
     Bioc-devel@r-project.org mailing list
     https://stat.ethz.ch/mailman/listinfo/bioc-devel

     _______________________________________________
     Bioc-devel@r-project.org mailing list
     https://stat.ethz.ch/mailman/listinfo/bioc-devel

     [[alternative HTML version deleted]]

     _______________________________________________
     [23]Bioc-devel@r-project.org mailing list
     [24]https://stat.ethz.ch/mailman/listinfo/bioc-devel

   _______________________________________________
   [25]Bioc-devel@r-project.org mailing list
   [26]https://stat.ethz.ch/mailman/listinfo/bioc-devel

References

   1. mailto:dtenenba@fredhutch.org
   2. mailto:andrzej.oles@gmail.com
   3. mailto:dtenenba@fredhutch.org
   4. mailto:bioc-devel@r-project.org
   5. mailto:whuber@embl.de
   6. http://bioconductor.org/checkResults/devel/bioc-LATEST/flowcatchR/
   7. mailto:dtenenba@fredhutch.org
   8. mailto:andrzej.oles@gmail.com
   9. mailto:whuber@embl.de
  10. mailto:bioc-devel@r-project.org
  11. http://bioconductor.org/checkResults/devel/bioc-LATEST/EBImage/
  12. http://bioconductor.org/packages/3.2/bioc/html/imageHTS.html
  13. mailto:whuber@embl.de
  14. mailto:Ludwig.Geistlinger@bio.ifi.lmu.de
  15. mailto:Ludwig.Geistlinger@bio.ifi.lmu.de
  16. mailto:Ludwig.Geistlinger@bio.ifi.lmu.de
  17. mailto:luo_weijun@yahoo.com
  18. mailto:maintainer@bioconductor.org
  19. mailto:dtenenba@fredhutch.org
  20. mailto:mtmorgan@fredhutch.org
  21. mailto:Bioc-devel@r-project.org
  22. http://bioconductor.org/checkResults/release/bioc-LATEST/KEGGREST/morelia-buildsrc.html
  23. mailto:Bioc-devel@r-project.org
  24. https://stat.ethz.ch/mailman/listinfo/bioc-devel
  25. mailto:Bioc-devel@r-project.org
  26. https://stat.ethz.ch/mailman/listinfo/bioc-devel
