github.com/rita33cool1/iot-system-gateway@v0.0.0-20200911033302-e65bde238cc5/docker-engine/ROADMAP.md (about)

     1  Moby Project Roadmap
     2  ====================
     3  
     4  ### How should I use this document?
     5  
     6  This document provides description of items that the project decided to prioritize. This should
     7  serve as a reference point for Moby contributors to understand where the project is going, and
     8  help determine if a contribution could be conflicting with some longer term plans.
     9  
    10  The fact that a feature isn't listed here doesn't mean that a patch for it will automatically be
    11  refused! We are always happy to receive patches for new cool features we haven't thought about,
    12  or didn't judge to be a priority. Please however understand that such patches might take longer
    13  for us to review.
    14  
    15  ### How can I help?
    16  
    17  Short term objectives are listed in
    18  [Issues](https://github.com/moby/moby/issues?q=is%3Aopen+is%3Aissue+label%3Aroadmap). Our
    19  goal is to split down the workload in such way that anybody can jump in and help. Please comment on
    20  issues if you want to work on it to avoid duplicating effort! Similarly, if a maintainer is already
    21  assigned on an issue you'd like to participate in, pinging him on GitHub to offer your help is
    22  the best way to go.
    23  
    24  ### How can I add something to the roadmap?
    25  
    26  The roadmap process is new to the Moby Project: we are only beginning to structure and document the
    27  project objectives. Our immediate goal is to be more transparent, and work with our community to
    28  focus our efforts on fewer prioritized topics.
    29  
    30  We hope to offer in the near future a process allowing anyone to propose a topic to the roadmap, but
    31  we are not quite there yet. For the time being, it is best to discuss with the maintainers on an
    32  issue, in the Slack channel, or in person at the Moby Summits that happen every few months.
    33  
    34  # 1. Features and refactoring
    35  
    36  ## 1.1 Runtime improvements
    37  
    38  We introduced [`runC`](https://runc.io) as a standalone low-level tool for container
    39  execution in 2015, the first stage in spinning out parts of the Engine into standalone tools.
    40  
    41  As runC continued evolving, and the OCI specification along with it, we created
    42  [`containerd`](https://github.com/containerd/containerd), a daemon to control and monitor `runC`.
    43  In late 2016 this was relaunched as the `containerd` 1.0 track, aiming to provide a common runtime
    44  for the whole spectrum of container systems, including Kubernetes, with wide community support.
    45  This change meant that there was an increased scope for `containerd`, including image management
    46  and storage drivers.
    47  
    48  Moby will rely on a long-running `containerd` companion daemon for all container execution
    49  related operations. This could open the door in the future for Engine restarts without interrupting
    50  running containers. The switch over to containerd 1.0 is an important goal for the project, and
    51  will result in a significant simplification of the functions implemented in this repository.
    52  
    53  ## 1.2 Internal decoupling
    54  
    55  A lot of work has been done in trying to decouple Moby internals. This process of creating
    56  standalone projects with a well defined function that attract a dedicated community should continue.
    57  As well as integrating `containerd` we would like to integrate [BuildKit](https://github.com/moby/buildkit)
    58  as the next standalone component.
    59  
    60  We see gRPC as the natural communication layer between decoupled components.
    61  
    62  ## 1.3 Custom assembly tooling
    63  
    64  We have been prototyping the Moby [assembly tool](https://github.com/moby/tool) which was originally
    65  developed for LinuxKit and intend to turn it into a more generic packaging and assembly mechanism
    66  that can build not only the default version of Moby, as distribution packages or other useful forms,
    67  but can also build very different container systems, themselves built of cooperating daemons built in
    68  and running in containers. We intend to merge this functionality into this repo.