Auto saved by Logseq
This commit is contained in:
@@ -0,0 +1,66 @@
|
||||
---
|
||||
tags:
|
||||
|
||||
- '#conferences'
|
||||
- '#papersubmission'
|
||||
- '#deadlines'
|
||||
- '#paper/msr11'
|
||||
- '#re'
|
||||
---
|
||||
# MSR20201
|
||||
## Sources
|
||||
|
||||
URL: [MSR 2021 (researchr.org)](https://conf.researchr.org/home/msr-2021)
|
||||
CFP: [MSR 2021 - Technical Papers - MSR 2021 (msrconf.org)](https://2021.msrconf.org/track/msr-2021-technical-papers#Call-for-Papers)
|
||||
## Important dates
|
||||
- Tue 5 Jan 2021 Abstract Submission
|
||||
- Tue 12 Jan 2021 Full Paper Submission
|
||||
- Wed 10 Feb - Fri 12 Feb 2021 Authors Response
|
||||
- Mon 22 Feb 2021 Notification
|
||||
- Mon 22 Mar 2021 Camera-Ready
|
||||
## Working notes during the revision
|
||||
- [ ] Check if the concept of upgrade plan is clear. Here we do not want to manage the actual migration (Sec 3)
|
||||
- [ ] Check if the problem about which library is used to trigger the process is relevant
|
||||
- [x] Menzionare GitHub dependency bot in the introduction
|
||||
- Il processo da presentare e'
|
||||
- I see the process as follows:
|
||||
1. Identification of vulnerable library
|
||||
2. Identification of the target version for the library in 1)
|
||||
3. Identification of the target versions for other used libraries that need to be upgraded because of the upgrade in 2)
|
||||
- Doubts:
|
||||
- To recommend single library upgrades I need a lot of data. Maybe it's too late when I'll be able to provide recommendations!!!
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
|
||||
librarySelection[Identification of the library to be updated] --> libraryVersion
|
||||
libraryVersion[Identification of the target version] -->setVersion
|
||||
setVersion[Update plan for all the involved libraries]
|
||||
|
||||
```
|
||||
### Some motivations
|
||||
|
||||
Nel paper
|
||||
|
||||
> R. G. Kula, D. M. German, A. Ouni, T. Ishio, e K. Inoue, «Do developers update their library dependencies?: An empirical study on the impact of security advisories on library migration», _Empir Software Eng_, vol. 23, n. 1, pagg. 384–417, feb. 2018, doi: [10.1007/s10664-017-9521-5](https://doi.org/10.1007/s10664-017-9521-5).
|
||||
> @article{kulaDevelopersUpdateTheir2018,
|
||||
|
||||
title = {Do Developers Update Their Library Dependencies?: {{An}} Empirical Study on the Impact of Security Advisories on Library Migration},
|
||||
shorttitle = {Do Developers Update Their Library Dependencies?},
|
||||
author = {Kula, Raula Gaikovina and German, Daniel M. and Ouni, Ali and Ishio, Takashi and Inoue, Katsuro},
|
||||
year = {2018},
|
||||
month = feb,
|
||||
volume = {23},
|
||||
pages = {384--417},
|
||||
issn = {1382-3256, 1573-7616},
|
||||
doi = {10.1007/s10664-017-9521-5},
|
||||
annotation = {00001},
|
||||
journal = {Empirical Software Engineering},
|
||||
language = {en},
|
||||
number = {1}
|
||||
}
|
||||
|
||||
Si dice:
|
||||
- although system heavily depend on libraries, most systems rarely update their libraries and systems are less likely migrate their library dependencies, with 81.5% of systems remaining with a popular older versions.
|
||||
- Moreover there exist patterns where an older popular library version is still preferred even in case of a security advisory disclosure. They find developers are less likely to update a library that requires more migration effort and vice-versa.
|
||||
- Developers evaluate the decision whether or not to update dependencies based on project specific priorities. Developers cite migration as a practice that requires extra migration effort and added responsibility.
|
||||
Reference in New Issue
Block a user