Feature/readme (#9)

* Update README for docker socket

* fix README typo

* run apt-get update first

* Update README

DEVELOPING.md

@@ -0,0 +1,75 @@
+# ZFS Builder Development
+
+For general information about contributing changes, see the
+[Contributor Guidelines](https://github.com/titan-data/.github/blob/master/CONTRIBUTING.md).
+
+## How it Works
+
+ZFS, like other kernel modules, has a dependency on the interfaces of the
+running kernel. Normally, this is built against the currently running kernel.
+But this creates challenges for users to always install all the requisite build
+tools and find the requisite kernel source, not to mention cases where you
+might want to build packages for a kernel other than the one you are currently
+running (such as part of an automated process using standard build machines).
+
+The ZFS builder will determine the build strategy based on the kernel variant
+being used. This strategy could build within the running container, could
+fetch pre-existing binaries, or simple build from source. The ZFS builder
+container is always launched with privileges to run other docker containers,
+so that systems that need it (CentOS and LinuxKit, for example) can build
+images and/or run containers.
+
+Each build strategy consists of some combination of:
+
+ 1. Clone `https://github.com/zfsonlinux/zfs.git`
+ 2. If a kernel build is required, download or build kernel-specific modules and
+    headers
+ 3. Build ZFS
+ 4. Copy the resulting binaries to `/build`
+
+### Adding new support
+
+All of the docker files are located under `src/`. The `build.sh` file kicks off
+the main build process, which consists of:
+
+  * Determine the build variant to use, based on uname values (e.g. `ubuntu`)
+  * Invoke the `build()` function in the variant-specific build file (e.g. `ubuntu.sh`)
+
+This provides maximum flexibility for a new variant to implement whatever build
+process they need. This could include downloading special packages, running
+containers, etc. For example, Ubuntu will run the build within the current image,
+while CentOS will launch a separate CentOS container to actually do the build.
+
+There are a number of helper functions in `common.sh` that are used across
+platforms, mostly to fetch and build ZFS source. These can be invoked at the
+appropriate point within the variant-specific build process. For example,
+LinuxKit and Ubuntu invoke them within the build container, while CentOS
+propagates it into a custom container to do the whole build.
+
+## Building
+
+The build process is very simple, just run `docker build -t <tag> .`.
+
+## Testing
+
+There are no built-in tests. You can test a variety of platforms using
+the [zfs-builds](https://github.com/titan-data/zfs-builds) repository. You can
+test a single affected platform or, if you are making broad changes, across
+every known platform.
+
+## Releasing
+
+ This repository is connected to the [titandata](https://hub.docker.com/u/titandata)
+ DockerHub organization via GitHub actions. It uses the standard DockerHub
+ build infrastructure to automatically build new images:
+
+  * Every push will update the `:develop` tag
+  * Every release will update the `:latest` tag
+  * Every release will create a `:[release]` tag
+
+New release should be named `v[major].[minor].[patch]`. While there are no
+strict rules, major releases should be reserved for changes that backwards
+compatibility with how the container is invoked. Minor releases should be
+reserved for forward-compatible changes to how it's invoked (e.g. a new
+option for a particular variant). Patch releases should be reserved for all
+other changes (including new variant support).

README.md

@@ -70,64 +70,18 @@ be used:
 This builder only works with ZFS version 0.8.0 or later, as the spl repository
 has been merged and no longer needs to be built separately.
 
-## How it works
+## Contributing
 
-ZFS, like other kernel modules, has a dependency on the interfaces of the
-running kernel. Normally, this is built against the currently running kernel.
-But this creates challenges for users to always install all the requisite build
-tools and find the requisite kernel source, not to mention cases where you
-might want to build packages for a kernel other than the one you are currently
-running (such as part of an automated process using standard build machines).
+The ZFS builder project follows the Titan community best practices:
 
-To accomplish this, the ZFS builder does the following:
+  * [Contributing](https://github.com/titan-data/.github/blob/master/CONTRIBUTING.md)
+  * [Code of Conduct](https://github.com/titan-data/.github/blob/master/CODE_OF_CONDUCT.md)
+  * [Community Support](https://github.com/titan-data/.github/blob/master/SUPPORT.md)
 
- 1. Clone `https://github.com/zfsonlinux/zfs.git` into `/src/zfs` and
-    checks out the appropriate tag (unless `/src/zfs` already exists)
- 2. Build the kernel, if necessary. First check the kernel release variant and,
-    if a known distro, download pre-built kernel headers, objects, and/or source
-    through distro-specific means. Otherwise get the source from `www.kernel.org`
-    and build it by hand.
- 3. Build `/src/zfs`
- 4. Copy the resulting binaries to `/build`
+It is maintained by the [Titan community maintainers](https://github.com/titan-data/.github/blob/master/MAINTAINERS.md)
 
-## Contribute
-
-1.  Fork the project.
-2.  Make your bug fix or new feature.
-3.  Add tests for your code.
-4.  Send a pull request.
-
-Contributions must be signed as `User Name <user@email.com>`. Make sure to
-[set up Git with user name and email address](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup).
-All development should be done on the `master` branch.
-
-#### Code of Conduct
-
-This project operates under the
-[Delphix Code of Conduct](https://delphix.github.io/code-of-conduct.html). By
-participating in this project you agree to abide by its terms.
-
-#### Contributor Agreement
-
-All contributors are required to sign the Delphix Contributor agreement prior
-to contributing code to an open source repository. This process is handled
-automatically by [cla-assistant](https://cla-assistant.io/). Simply open a pull
-request and a bot will automatically check to see if you have signed the latest
-agreement. If not, you will be prompted to do so as part of the pull request
-process.
-
-
-## Reporting Issues
-
-Issues should be reported [here](https://github.com/delphix/zfs-builder/issues).
-
-## Statement of Support
-
-This software is provided as-is, without warranty of any kind or commercial
-support through Delphix. See the associated license for additional details.
-Questions, issues, feature requests, and contributions should be directed to
-the community as outlined in the
-[Delphix Community Guidelines](https://delphix.github.io/community-guidelines.html).
+For more information on how it works, and how to build and release new versions,
+see the [Development Guidelines](DEVELOPING.md).
 
 ## License