  Background. Containerization technologies are widely adopted in the DevOps
workflow. The most commonly used one is Docker, which requires developers to
define a specification file (Dockerfile) to build the image used for creating
containers. There are several best practice rules for writing Dockerfiles, but
the developers do not always follow them. Violations of such practices, known
as Dockerfile smells, can negatively impact the reliability and the performance
of Docker images. Previous studies showed that Dockerfile smells are widely
diffused, and there is a lack of automatic tools that support developers in
fixing them. However, it is still unclear what Dockerfile smells get fixed by
developers and to what extent developers would be willing to fix smells in the
first place.
  Objective. The aim of our exploratory study is twofold. First, we want to
understand what Dockerfiles smells receive more attention from developers,
i.e., are fixed more frequently in the history of open-source projects. Second,
we want to check if developers are willing to accept changes aimed at fixing
Dockerfile smells (e.g., generated by an automated tool), to understand if they
care about them.
  Method. In the first part of the study, we will evaluate the survivability of
Dockerfile smells on a state-of-the-art dataset composed of 9.4M unique
Dockerfiles. We rely on a state-of-the-art tool (hadolint) for detecting which
Dockerfile smells disappear during the evolution of Dockerfiles, and we will
manually analyze a large sample of such cases to understand if developers fixed
them and if they were aware of the smell. In the second part, we will detect
smelly Dockerfiles on a set of GitHub projects, and we will use a rule-based
tool to automatically fix them. Finally, we will open pull requests proposing
the modifications to developers, and we will quantitatively and qualitatively
evaluate their outcome.
