Bug#961371: ITP: due -- Wrapper tool to create and run Docker container software build environments.

[adoyle <alexddoyle@gmail.com>]

Package: wnpp
Severity: wishlist
Owner: adoyle <alexddoyle@gmail.com>

* Package name    : due
  Version         : 1.3.1
  Upstream Author : Alex Doyle <alexddoyle@gmail.com>
* URL             : https://github.com/CumulusNetworks/DUE
* License         : MIT
  Programming Lang: Bash
  Description     : Wrapper tool to create and run Docker container software build environments.

Dedicated User Environment (DUE) is a framework for creating preconfigured build/development
environments in Docker containers. It serves two primary purposes:

1 - Maintains configurations for creating Docker images for any build environment, using
any architecture of any Debian based release it can find an image for.
 For example, the Open Network Install Environment (https://github.com/opencomputeproject/onie)
 currently builds on Debian 8 and 9, but requires some Backports packages, and a program that
 isn't packaged for Debian. DUE maintains a configuration to get all of that added when the
 Docker image is created so ONIE can 'just build'. Apart from not requiring the end user to
 have to configure the build environment, it also allows all developers to use the same build
 environment when debugging - regardless of where they happen to be.

2 - It goes beyond 'just using a Dockerfile' by using a launcher application that supplies
runtime configuration to Docker for the Docker images it has created. Apart from reducing
typing and being smart about the containers that it runs (ex: containers building Debian
packages mount the host directory _above_ the build directory so the resulting .debs aren't
stored in the container), DUE preserves the user's identity in the container by creating an account
for them with their user ID, and mounting their home directory so they can access their .config files.
This creates a less intrusive development environment when the user is in a build/test/debug
cycle.

While the above are the most important features DUE provides, there are a lot more ways
it makes using different development configurations easier, which are documented in
the Readme.md (https://github.com/CumulusNetworks/DUE/blob/master/README.md)

I also created a tutorial video using DUE to build ONIE as part of a talk I gave at
OpenCompute here: https://www.youtube.com/watch?v=-5onRbZA0QQ&feature=youtu.be

History:
 DUE came out of work I did at Cumulus Networks to provide build environments for
 teams of engineers building packages for Cumulus' Jessie and Buster based
 releases of Cumulus Linux. When I took over as ONIE Project Lead, I saw the opportunity
 to use it to create a standard way of setting up build environments for ONIE and any other
 software projects. Cumulus saw the value in any developer being able to use it
 and DUE was open sourced under the MIT license.

Q&A:
Why is this package useful/relevant?
 See above.

Is it a dependency for another package?
 No. It does require a version ( Debian or upstream ) of Docker to work though.

Do you use it?
 All. The. Time.  Building packages at work, building ONIE, and if I just need
 an environment to quickly test configuration changes.
 This 'dogfooding' has provided insight into fixing program behaviors that
 initially seemed okay, and then became irritating through repeated use.

If there are other packages providing similar functionality, how does it compare?
 I looked around for quite a while before starting on DUE ( why reinvent the wheel?),
 but couldn't find anything that had the combination of:
  - Consistent, user friendly interface
  - Easy build environment configuration
  - And support for Debian derivatives
  ...that I was looking for.
 
 I think the closest software to this would be using schroots, and while they
 can be functionally the same, the end user experience, especially for users that
 are new to Debian ( or are trying to build code that partially exists outside
 the Debian ecosystem ) has less of a learning curve, and is faster to set up.
 
How do you plan to maintain it?
 I will be updating the upstream source and doing the work to make sure it is
 Debian compliant.
 
Are you looking for co-maintainers?
 Not at the moment.
 
Do you need a sponsor?
 Yes, as I am not a Debian Developer ( in the official sense, anyway :) )
 
Thank you for your consideration,
Alex Doyle