A lot of new code has been added in the last release to ship new features as soon as possible. Now that the v0.10 release is out we should take a step back and solidify the codebase to make sure we have a good foundation for future developments.

Rather than some local cleanups and renames, I'm more interested if the scope and dependencies for packages make sense. Should we have a new package or interface to have a clear separation of responsibilities between components?

Some problem areas that have grown a lot:

• Cache/blobs/mergeop/remote management
  • Lazy refs
  • Cacheopts
  • Blob reference management
  • Interaction with snapshot layer
  • Do these designs make sense looking back at them now?
• Dockerfile
  • I think dispatch/dockerfile2llb logic needs reorganization to support more new features like warnings, named contexts, buildinfo, frontend capabilities.

Other approaches:

• Check dependencies for a package. Does the list make sense? A config package should not depend on 20 other packages. cache package should not depend on solver like it does now.
• Look for functions that takes 5+ parameters as every new feature has added a new one. These should be combined into logical structures.
• Check gocyclo. There is no goal to have everything under certain complexity, but it can point to some troublesome areas.
• Check code that has been marked deprecated a long time ago and should be removed.

Action plan:

We need to avoid big PRs and prefer many smaller PRs with well-defined small scope, so they don't get stuck in review. There are many ways to write the same functionality, and we should avoid changes where the improvement is not clear.

Before working on something, make a special issue for it or comment here. In some cases, you need to try an improvement before you can see if it really helps but at least proposed package/interface level changes should have a design proposal first.

Please post other problem areas or ideas in the comments.

@sipsma @ktock @crazy-max