papers: add DOIs and pages for SANER papers
authorStefano Zacchiroli <zack@upsilon.cc>
Sat, 18 Apr 2020 11:17:40 +0000 (13:17 +0200)
committerStefano Zacchiroli <zack@upsilon.cc>
Sat, 18 Apr 2020 11:17:40 +0000 (13:17 +0200)
research/publications.mdwn
research/publications/saner-2020-deps.bib
research/publications/saner-2020-swh-graph.bib

index fabf156..32adca1 100644 (file)
@@ -220,20 +220,22 @@ You might also be interested in my author profiles on
     [[!toggle id=id79 text="Abstract..."]] [[!toggleable id=id79 text="""
     *Abstract:* The notion of software "fork" has been shifting over time from the (negative) phenomenon of community disagreements that result in the creation of separate development lines and ultimately software products, to the (positive) practice of using distributed version control system (VCS) repositories to collaboratively improve a single product without stepping on each others toes. In both cases the VCS repositories participating in a fork share parts of a common development history. Studies of software forks generally rely on hosting platform metadata, such as GitHub, as the source of truth for what constitutes a fork. These “forge forks” however can only identify as forks repositories that have been created on the platform, e.g., by clicking a "fork" button on the platform user interface. The increased diversity in code hosting platforms (e.g., GitLab) and the habits of significant development communities (e.g., the Linux kernel, which is not primarily hosted on any single platform) call into question the reliability of trusting code hosting platforms to identify forks. Doing so might introduce selection and methodological biases in empirical studies. In this article we explore various definitions of "software forks", trying to capture forking workflows that exist in the real world. We quantify the differences in how many repositories would be identified as forks on GitHub according to the various definitions, confirming that a significant number could be overlooked by only considering forge forks. We study the structure and size of fork networks, observing how they are affected by the proposed definitions and discuss the potential impact on empirical research.
     """]]
- 1. <a class="paper-download" href="saner-2020-swh-graph.pdf" title="download paper in PDF format">[.pdf]</a> <a class="bibtex-download" href="saner-2020-swh-graph.bib" title="download bibliographic entry in BibTeX format">[.bib]</a> <a href="http://boldi.di.unimi.it/">Paolo Boldi</a>, <a href="https://koin.fr/">Antoine Pietri</a>, <a href="http://vigna.di.unimi.it/">Sebastiano Vigna</a>, <a href="http://upsilon.cc/~zack">Stefano Zacchiroli</a>. **Ultra-Large-Scale Repository Analysis via Graph Compression**.  <em>
+ 1. <a class="paper-download" href="saner-2020-swh-graph.pdf" title="download paper in PDF format">[.pdf]</a> <a class="bibtex-download" href="saner-2020-swh-graph.bib" title="download bibliographic entry in BibTeX format">[.bib]</a> <span class="doi_logo"><a href="http://dx.doi.org/10.1109/SANER48275.2020.9054827" title="Document Object Identifier">doi&gt;</a></span> <a href="http://boldi.di.unimi.it/">Paolo Boldi</a>, <a href="https://koin.fr/">Antoine Pietri</a>, <a href="http://vigna.di.unimi.it/">Sebastiano Vigna</a>, <a href="http://upsilon.cc/~zack">Stefano Zacchiroli</a>. **Ultra-Large-Scale Repository Analysis via Graph Compression**.  <em>
        In proceedings of <a href="https://saner2020.csd.uwo.ca/">SANER 2020</a>: The 27th IEEE
        International Conference on Software Analysis, Evolution and
        Reengineering, February 18-21, 2020, London, Ontario,
-       Canada. IEEE 2020.
+       Canada, <a href="https://ieeexplore.ieee.org/document/9054827">pp. 184-194</a>.
+       IEEE 2020.
       </em>
     [[!toggle id=id77 text="Abstract..."]] [[!toggleable id=id77 text="""
     *Abstract:* We consider the problem of mining the development history—as captured by modern version control systems—of ultra-large-scale software archives (e.g., tens of millions software repositories corresponding). We show that graph compression techniques can be applied to the problem, dramatically reducing the hardware resources needed to mine similarly-sized corpus. As a concrete use case we compress the full Software Heritage archive, consisting of 5 billion unique source code files and 1 billion unique commits, harvested from more than 80 million software projects—encompassing a full mirror of GitHub. The resulting compressed graph fits in less than 100 GB of RAM, corresponding to a hardware cost of less than 300 U.S. dollars. We show that the compressed in-memory representation of the full corpus can be accessed with excellent performances, with edge lookup times close to memory random access. As a sample exploitation experiment we show that the compressed graph can be used to conduct clone detection at this scale, benefiting from main memory access speed.
     """]]
- 1. <a class="paper-download" href="saner-2020-deps.pdf" title="download paper in PDF format">[.pdf]</a> <a class="bibtex-download" href="saner-2020-deps.bib" title="download bibliographic entry in BibTeX format">[.bib]</a> <a href="http://mancoosi.org/~abate/about-me">Pietro Abate</a>, <a href="http://www.dicosmo.org">Roberto Di Cosmo</a>, <a href="http://www.gousios.gr/">Georgios Gousios</a>, <a href="http://upsilon.cc/~zack">Stefano Zacchiroli</a>. **Dependency Solving Is Still Hard, but We Are Getting Better at It**.  <em>
+ 1. <a class="paper-download" href="saner-2020-deps.pdf" title="download paper in PDF format">[.pdf]</a> <a class="bibtex-download" href="saner-2020-deps.bib" title="download bibliographic entry in BibTeX format">[.bib]</a> <span class="doi_logo"><a href="http://dx.doi.org/10.1109/SANER48275.2020.9054837" title="Document Object Identifier">doi&gt;</a></span> <a href="http://mancoosi.org/~abate/about-me">Pietro Abate</a>, <a href="http://www.dicosmo.org">Roberto Di Cosmo</a>, <a href="http://www.gousios.gr/">Georgios Gousios</a>, <a href="http://upsilon.cc/~zack">Stefano Zacchiroli</a>. **Dependency Solving Is Still Hard, but We Are Getting Better at It**.  <em>
        In proceedings of <a href="https://saner2020.csd.uwo.ca/">SANER 2020</a>: The 27th IEEE
        International Conference on Software Analysis, Evolution and
        Reengineering, February 18-21, 2020, London, Ontario,
-       Canada. IEEE 2020.
+       Canada, <a href="https://ieeexplore.ieee.org/document/9054837">pp. 547-551</a>.
+       IEEE 2020.
       </em>
     [[!toggle id=id76 text="Abstract..."]] [[!toggleable id=id76 text="""
     *Abstract:* Dependency solving is a hard (NP-complete) problem in all non-trivial component models due to either mutually incompatible versions of the same packages or explicitly declared package conflicts. As such, software upgrade planning needs to rely on highly specialized dependency solvers, lest falling into pitfalls such as incompleteness—a combination of package versions that satisfy dependency constraints does exist, but the package manager is unable to find it. In this paper we look back at proposals from dependency solving research dating back a few years. Specifically, we review the idea of treating dependency solving as a separate concern in package manager implementations, relying on generic dependency solvers based on tried and tested techniques such as SAT solving, PBO, MILP, etc. By conducting a census of dependency solving capabilities in state-of-the-art package managers we conclude that some proposals are starting to take off (e.g., SAT-based dependency solving) while—with few exceptions—others have not (e.g., outsourcing dependency solving to reusable components). We reflect on why that has been the case and look at novel challenges for dependency solving that have emerged since.
index 13ee995..f4e7bb2 100644 (file)
@@ -4,5 +4,7 @@
   abstract = {Dependency solving is a hard (NP-complete) problem in all non-trivial component models due to either mutually incompatible versions of the same packages or explicitly declared package conflicts. As such, software upgrade planning needs to rely on highly specialized dependency solvers, lest falling into pitfalls such as incompleteness—a combination of package versions that satisfy dependency constraints does exist, but the package manager is unable to find it. In this paper we look back at proposals from dependency solving research dating back a few years. Specifically, we review the idea of treating dependency solving as a separate concern in package manager implementations, relying on generic dependency solvers based on tried and tested techniques such as SAT solving, PBO, MILP, etc. By conducting a census of dependency solving capabilities in state-of-the-art package managers we conclude that some proposals are starting to take off (e.g., SAT-based dependency solving) while—with few exceptions—others have not (e.g., outsourcing dependency solving to reusable components). We reflect on why that has been the case and look at novel challenges for dependency solving that have emerged since.},
   publisher = {IEEE},
   year = {2020},
+  doi = {10.1109/SANER48275.2020.9054837},
+  pages = {547-551},
   booktitle = {SANER 2020: The 27th IEEE International Conference on Software Analysis, Evolution and Reengineering},
 }
index ff6ea6e..ae2bdc6 100644 (file)
@@ -4,5 +4,7 @@
   abstract = {We consider the problem of mining the development history—as captured by modern version control systems—of ultra-large-scale software archives (e.g., tens of millions software repositories corresponding). We show that graph compression techniques can be applied to the problem, dramatically reducing the hardware resources needed to mine similarly-sized corpus. As a concrete use case we compress the full Software Heritage archive, consisting of 5 billion unique source code files and 1 billion unique commits, harvested from more than 80 million software projects—encompassing a full mirror of GitHub. The resulting compressed graph fits in less than 100 GB of RAM, corresponding to a hardware cost of less than 300 U.S. dollars. We show that the compressed in-memory representation of the full corpus can be accessed with excellent performances, with edge lookup times close to memory random access. As a sample exploitation experiment we show that the compressed graph can be used to conduct clone detection at this scale, benefiting from main memory access speed.},
   publisher = {IEEE},
   year = {2020},
+  doi = {10.1109/SANER48275.2020.9054827},
+  pages = {184-194},
   booktitle = {SANER 2020: The 27th IEEE International Conference on Software Analysis, Evolution and Reengineering},
 }