more ci stuff

service/ci.md

@@ -27,7 +27,8 @@ The [GitLab CI quickstart][] should get you started here. Note that
 there are some "shared runners" you can already use, and which should
 be available to all projects.
 
-TODO: time limits? should we say how to enable the shared runners?
+TODO: do runners have time limits? should we document how to enable
+the shared runners in a project?
 
 # How-to
 
@@ -39,7 +40,7 @@ TODO: time limits? should we say how to enable the shared runners?
 <!-- how to deal with them. this should be easy to follow: think of -->
 <!-- your future self, in a stressful situation, tired and hungry. -->
 
-TODO: what happens if there's trouble with the f-droid runners? who to
+TODO: @ahf what happens if there's trouble with the f-droid runners? who to
 ping? anything we can do to diagnose the problem? what kind of
 information to send them?
 
@@ -60,7 +61,7 @@ GitLab.
 
 ### Linux
 
-TODO: document how the F-Droid runners were hooked up to GitLab
+TODO: @ahf document how the F-Droid runners were hooked up to GitLab
 CI. Anything special on top of [the official docs](https://docs.gitlab.com/runner/register/)?
 
 ### MacOS/Windows
@@ -75,14 +76,10 @@ The GitLab CI service is offered on a "best effort" basis and might
 not be fully available.
 
 ## Design
-<!-- how this is built -->
-<!-- should reuse and expand on the "proposed solution", it's a -->
-<!-- "as-built" documented, whereas the "Proposed solution" is an -->
-<!-- "architectural" document, which the final result might differ -->
-<!-- from, sometimes significantly -->
 
-<!-- a good guide to "audit" an existing project's design: -->
-<!-- https://bluesock.org/~willkg/blog/dev/auditing_projects.html -->
+TODO: expand on GitLab CI's design and architecture, following [this
+checklist](https://bluesock.org/~willkg/blog/dev/auditing_projects.html). See also the [Jenkins section](#Jenkins) below for the same
+thing about Jenkins.
 
 ## Issues
 
@@ -330,3 +327,40 @@ system](howto/static-component). See the [alternatives to the static site
 system](static-component#Alternatives-considered) for more information.
 
 [Jenkins CI]: https://en.wikipedia.org/wiki/Jenkins_(software)
+
+TODO: "audit" jenkins as per [this document](https://bluesock.org/~willkg/blog/dev/auditing_projects.html), possibly in its own
+"jenkins" service page.
+
+In particular, we need to answer:
+
+ * Why does this project exist?
+ * What does this project do?
+ * What is the context in which it exists?
+ * Who has worked on this project in the past? (@weasel?)
+ * Who is currently working on this project? (@weasel? @hiro?)
+ * Who are the stake-holders? Who "owns" the service/application?
+   (@weasel is the service admin i believe)
+ * Who will cry out in anguish when the service/application goes down?
+   (lots? which team still use it?)
+ * Are there other projects that depend on it? What are they? (same as
+   above?)
+ * Are there possible future users that this project is working
+   towards? (maybe more a question for GitLab CI)
+ * Is there an active community around this project? (Jenkins is still
+   healthy, actually, but not well supported in Debian)
+
+ * design and architecture? do we really need to dive into this? would
+   include stuff like:
+   * What are the major components, services, storage systems, queues,
+     etc for the project?
+   * What data does the project use and how does it flow through the
+     system?
+   * What languages, versions, and runtimes are used?
+   * interesting in the context of replacing with GitLab CI: What
+     infrastructure is used? How is it defined? Who is responsible?
+   * Is there a system for authentication/authorization? How does it
+     work? Who is responsible for the systems involved?
+   * where are the repos for control, which repos use it?
+ * security review?
+ * technical debt
+ * urgent stuff