Handling duplicates in Dockerfiles families:
Learning from experts
The corpus used for our experiment can be found here: corpus
All the duplicates we analyzed to identify the underlying reason for their exitence can be found here: Duplicates
The reason behind each duplicate id can be found here: Duplicates reasons
- How many Dockerfiles do you manage?
- This survey is for maintainers managing more than a single Dockerfile, do you still want to continue the survey?
- Do your Dockerfiles share duplicate instructions (see the following screenshot)?
- Have you ever updated several Dockerfiles in one commit to perform the same changes?
- How do you qualify such updates (the ones that perform several Dockerfiles)?
- You never updated several Dockerfiles in one commit. Can you explain why?
- Would you like to have a tool to detect the duplicate instructions?
- Why don't you want to have a tool to detect duplicate instuctions?
- In your opinion, what should be the minimal size for a duplicate bloc of instructions to be detected?
- Across how many Dockerfiles should these instructions/blocs of instructions be duplicated to be detected?
- Do you have tools to avoid these duplicate instructions across your Dockerfiles?
- What tools do you use?
- Are you satisfied with your actual tool?
- Why don't you use a tool to avoid these duplicate instructions?
- Would you like to have a tool built to avoid duplicates in Dockerfiles?
- Why don't you want to have a specific tool to avoid these duplicates?
- Do you think the Dockerfile DSL (Domain Specific Language) should have reuse mechanisms?
- What should these mechanisms help you reuse?
- Why do you think the Dockerfile DSL shouldn't have reuse mechanisms?
- If you want to have feedbacks about the experiment, please leave your e-mail (will be deleted when the study is over)
The results we gathered through our survey can be found here: Survey results
All variants and reuse strategies used by projects in our corpus can be found here: Reuse strategies and variants