#57 more docs

site/src/main/tut/docs/hacking.md

@@ -12,12 +12,14 @@ Aka the `DEVELOPERS` readme, if you want to get your hands dirty with the code,
 
 ## Quick Start (in an IDE)
 
-If you want to play with the source, you can build some test data by running the `Example` app from within IntelliJ.
+You can then start up the app from the `Main` class. 
 
-You can then start up the app from the `Main` class. If you want to override the sensor file location (for the case when you're testing without sensors), use `-Dsensor.location=src/test/resources/examples`.
+To override the sensor file location (for the case when you're testing without sensors), use `-Dsensor.location=src/test/resources/examples`.
 
 Check the web page with [http://localhost:11900](http://localhost:11900).
 
+If you want to add some test data, you can run the `Example` app (say, from within IntelliJ).
+
 
 ## Build the Web App
 

site/src/main/tut/docs/hacking/release.md

@@ -15,7 +15,7 @@ Each is managed separately but should be consistent in terms of the release arti
 
 To do this, we:
 
-1. Tag and release from the backend project using the `sbt-release` plugin and [Github releases](https://github.com/tobyweston/temperature-machine/releases)
+1. Tag and release from the backend project using [Github releases](https://github.com/tobyweston/temperature-machine/releases)
 1. As the UI project is copied into the backend project as JavaScript assets (using `build-webapp.sh`), the UI project is not tagged or released via Github
 1. After tagging, immediately run `release-debian-package.sh` to publish the tagged version to the debian repository
 
@@ -33,12 +33,19 @@ SHA updates are generally used to get small increments out without the overhead
 
 ## Tag and Release
 
-To do release, run the following
+To do release, draft a new release via the Github [release page](https://github.com/tobyweston/temperature-machine/releases).
 
-    sbt release
+We could look into automating this with the `sbt-release` plugin at some point. This would usually prepare a JAR, tag and copy the JAR to a local maven repo. We're not interested in publishing the JAR via a Maven repository, instead we want to create a Debian package and publish that.
 
-This would usually prepare a JAR, tag and copy the JAR to a local maven repo. We're not interested in publishing the JAR via a Maven repository, instead we want to create a Debian package and publish that.
+
+When done, create and deploy the Debian package (see below).
 
 
 ## Debian Package
 
+To create the Debian package and push it to the [Robotooling](http://robotooling.com/debian) repository, run the following:
+
+    ./release_debian_package.sh
+
+
+

site/src/main/tut/docs/hacking/sbt_plugins.md

@@ -24,14 +24,6 @@ Run the following to get an idea of test coverage.
 
 Check out the generated report under `target/scala-2.12/scoverage-report`. Remember good coverage doesn't always mean good tests!
 
-## sbt-release 
-
-<p class="bg-warning">
-Configured in <code>release.sbt</code>.
-</p>
-
-Used minimally as a convenience to tag a release.
-
 
 ## sbt-assembly