Start planning out v0.0.4 release

tasks/release/template.md

@@ -0,0 +1,27 @@
+---
+# This file is a template for new releases. It delineates all sub-tasks which
+# are common to a release.
+#
+# It is expected that this file will be copy-pasted into this directory and the
+# front-matter uncommented. Release goals should be added as dependencies via
+# `after`.
+#
+#type: task
+#after:
+#  - /bugs/**
+---
+
+# Release vX.Y.Z
+
+Checklist for the release:
+
+* Review all documentation to ensure it is up-to-date and complete.
+
+* Follow building instructions at `/docs/dev/releases.md` to create a release
+  candidate (RC), distribute RC to anyone who wants to test, collect feedback,
+  fix bugs, create new RC, rinse-repeat until confident.
+
+* Follow building _and_ releasing instructions at `/docs/dev/releases.md` to
+  complete release process.
+
+* Delete this file.

tasks/release/v0.0.4.md

@@ -0,0 +1,24 @@
+---
+type: task
+after:
+  - /bugs/**
+  - /windows-support/**
+  - /misc/minimize-joining-bootstrap-size.md
+  - /misc/omitempty-bootstrap.md
+  - /misc/set-config-cas.md
+---
+
+# Release vX.Y.Z
+
+Checklist for the release:
+
+* Review all documentation to ensure it is up-to-date and complete.
+
+* Follow building instructions at `/docs/dev/releases.md` to create a release
+  candidate (RC), distribute RC to anyone who wants to test, collect feedback,
+  fix bugs, create new RC, rinse-repeat until confident.
+
+* Follow building _and_ releasing instructions at `/docs/dev/releases.md` to
+  complete release process.
+
+* Delete this file.

tasks/windows-support/flags.md

@@ -0,0 +1,8 @@
+---
+type: task
+---
+
+Windows uses different patterns for command-line flags, ie forward slash rather
+than hypen for denoting options. It should be checked it pflags handles this
+automatically (doubtful), and if not if this is something that other
+cross-platform projects (e.g. docker) bother with.

tasks/windows-support/garage.md

@@ -0,0 +1,25 @@
+---
+type: task
+---
+
+Garage does not currently build for windows. A new build target needs to be
+developed within the garage project itself and incorporated here. Whatever work
+is done for that should be offered upstream, but they've already said they don't
+want to support garage so probably it won't get merged.
+
+## Metrics
+
+We should attempt to keep the `metrics` build feature of garage in-tact, even
+though this proved difficult in past attempts to port garage. It's possible that
+metrics will be the easiest way to programatically introspect on certain parts
+of garage's state, and we should keep that option open.
+
+## Unix-domain sockets support
+
+If [tokio windows UDS support][tokio-2201] ever gets sorted out it would make
+this easier, but in the meantime we'll have to remove support for UDS. This is
+fine, as we're deliberately not using it in garage (for this reason), but it
+would be nice to put the admin port (and maybe even s3 api port eventually) on a
+UDS.
+
+[tokio-2201]: https://github.com/tokio-rs/tokio/issues/2201

tasks/windows-support/packaging.md

@@ -0,0 +1,9 @@
+---
+type: task
+---
+
+It will be necessary to develop a windows installation binary (MSI) which
+installs Isle. From limited research it seems like [NSIS][nsis] will be the best
+option for this.
+
+[nsis]: https://nsis.sourceforge.io/

tasks/windows-support/permissions.md

@@ -0,0 +1,7 @@
+---
+type: task
+---
+
+It remains to be seen what the windows equivalent of linux capabilities are. In
+any case, it will be necessary that the isle daemon is able to be run with
+permission to create a VPN interface and listen on port 53.

tasks/windows-support/pmux.md

@@ -0,0 +1,7 @@
+---
+type: task
+---
+
+There's some specific thing that pmux is doing with process group IDs which
+is not supported on windows. In general pmux might benefit from some more
+intensive automated testing which can then help with porting it to windows.