Review

3 files changed, 21 insertions, 19 deletions

diff --git a/mod/mod-ci-github-gh.cxx b/mod/mod-ci-github-gh.cxx
index 28f21f7..5664a7a 100644
--- a/mod/mod-ci-github-gh.cxx
+++ b/mod/mod-ci-github-gh.cxx
@@ -14,11 +14,13 @@ namespace brep
   string
   gh_to_status (build_state st)
   {
-    // @@ Just return by value (small string optimization).
+    // Just return by value (small string optimization).
     //
-    //   @@ TMP Keep this comment, right?
-    //
-    return gh_status[static_cast<size_t> (st)];
+    switch (st)
+    {
+    case build_state::queued: return "QUEUED";
+      // @@ TODO: complete.
+    }
   }
 
   // Return the build_state corresponding to a GitHub check run status
diff --git a/mod/mod-ci-github-gh.hxx b/mod/mod-ci-github-gh.hxx
index 3898afd..0e4cf4e 100644
--- a/mod/mod-ci-github-gh.hxx
+++ b/mod/mod-ci-github-gh.hxx
@@ -138,6 +138,12 @@ namespace brep
     gh_installation_access_token () = default;
   };
 
+  string
+  gh_to_iso8601 (timestamp);
+
+  timestamp
+  gh_from_iso8601 (const string&);
+
   ostream&
   operator<< (ostream&, const gh_check_suite&);
 
@@ -155,12 +161,6 @@ namespace brep
 
   ostream&
   operator<< (ostream&, const gh_installation_access_token&);
-
-  string
-  to_iso8601 (timestamp);
-
-  timestamp
-  from_iso8601 (const string&);
 }
 
 #endif // MOD_MOD_CI_GITHUB_GH_HXX
diff --git a/mod/tenant-service.hxx b/mod/tenant-service.hxx
index 92d8747..2b76b2d 100644
--- a/mod/tenant-service.hxx
+++ b/mod/tenant-service.hxx
@@ -53,15 +53,15 @@ namespace brep
   // the correct order, this is currently done by imposing delays (some
   // natural, such as building->built, and some artificial, such as
   // queued->building). As result, it is unlikely but possible to be notified
-  // about the state transitions in the wrong order, especially if the
-  // notifications take a long time. To minimize the chance of this happening,
-  // the service implementation should strive to batch the queued state
-  // notifications (or which there could be hundreds) in a single request if
-  // at all possible. Also, if supported by the third-party API, it makes
-  // sense for the implementation to protect against overwriting later states
-  // with earlier. For example, if it's possible to place a condition on a
-  // notification, it makes sense to only set the state to queued if none of
-  // the later states (e.g., building) are already in effect.
+  // about the state transitions in the wrong order, especially if processing
+  // notifications can take a long time. To minimize the chance of this
+  // happening, the service implementation should strive to batch the queued
+  // state notifications (of which there could be hundreds) in a single
+  // request if at all possible. Also, if supported by the third-party API, it
+  // makes sense for the implementation to protect against overwriting later
+  // states with earlier. For example, if it's possible to place a condition
+  // on a notification, it makes sense to only set the state to queued if none
+  // of the later states (e.g., building) are already in effect.
   //
   // Note also that it's possible for the build to get deleted at any stage
   // without any further notifications. This can happen, for example, due to