| *** willbarnard has joined #trustable | 05:58 | |
| *** spinglet has joined #trustable | 07:26 | |
| *** toscalix has joined #trustable | 07:39 | |
| locallycompact | ditaa is a good find | 08:14 |
|---|---|---|
| locallycompact | http://zenhaskell.gitlab.io/shakebook/ | 08:14 |
| paulsherwood | ok, i think i'm sold | 08:32 |
| paulsherwood | i have an underlying worry about how far we take trustable into the tools we use... do we care about provenance of all our editors? do we really need to construct our whole documentation pipeline from known sources etc? | 08:33 |
| *** willbarnard has quit IRC | 08:34 | |
| locallycompact | if you construct that documentation pipeline from scratch it will take years | 08:52 |
| locallycompact | you'll have to build texlive | 08:52 |
| locallycompact | the dockers for zenhaskell are here, currently https://gitlab.com/zenhaskell/infra-dockers | 08:53 |
| *** Shaun has joined #trustable | 09:37 | |
| Shaun | Is there a way I can automatically connect to this channel when I start HexChat? It keeps resetting every day | 09:37 |
| locallycompact | network list > edit > Autojoin channels | 09:39 |
| Shaun | Thanks locallycompact | 09:40 |
| locallycompact | Shaun: ditaa was a great find btw | 09:46 |
| locallycompact | http://zenhaskell.gitlab.io/shakebook/ | 09:46 |
| Shaun | I can't take much credit, I found it on the wisdom page of the Codethink wiki | 09:46 |
| flatmush | STANDUP! Order: flatmush, Shaun, iker | 09:48 |
| flatmush | ## Ben Brewer (flatmush) | 09:48 |
| flatmush | * Done | 09:48 |
| flatmush | - Looked into systemd | 09:48 |
| flatmush | - Wrote e-mail about futility of systemd for minimal system. | 09:48 |
| flatmush | * Doing | 09:48 |
| flatmush | - Look into alternative init systems | 09:48 |
| flatmush | ## Shaun Mooney (Shaun) | 09:48 |
| Shaun | * Done | 09:48 |
| Shaun | - Drawn control model functional diagram | 09:48 |
| Shaun | - Pushed control diagram to repo | 09:48 |
| Shaun | * Doing | 09:48 |
| Shaun | - Writing up autonomous car STPA | 09:48 |
| Shaun | - Losses and Hazards | 09:48 |
| Shaun | - Detail responsibilites and control actions | 09:48 |
| Shaun | - Docker with ditaa and pandoc to publish docs | 09:48 |
| Shaun | * Next | 09:48 |
| Shaun | - Install XSTAMPP and draw autonomous control model | 09:48 |
| Shaun | * Issues | 09:48 |
| Shaun | - None | 09:49 |
| Shaun | ## Iker Perez ( iker ) | 09:49 |
| iker | 09:49 | |
| iker | * Done | 09:49 |
| iker | - Add latency-measure test to test-minimal-system | 09:49 |
| iker | * Doing | 09:49 |
| iker | - Make work latency-measure in the CI | 09:49 |
| iker | - Analyse the way the minimal distro uses buildstream | 09:49 |
| iker | - Add gitect to the repo (Issue #2) | 09:49 |
| iker | # Discussion | 09:49 |
| Shaun | _o_ | 09:49 |
| iker | _o_ | 09:49 |
| flatmush | STANDUP ENDS! | 09:49 |
| locallycompact | Shaun: I've published a docker with pandoc and dihaa in it as part of my ci if you like to use that: https://hub.docker.com/r/zenhaskell/analysis/ | 09:57 |
| locallycompact | It just requires calling dihaa, (not ditaa) | 09:57 |
| locallycompact | I don't know if the command line interfaces are equivalent | 09:58 |
| Shaun | locallycompact: great, thanks! | 09:59 |
| Shaun | Just installing docker (which isn't as simple as I thought it would be), then will give it a go | 09:59 |
| Shaun | locallycompact: I'm getting "Error response from daemon: manifest for zenhaskell/analysis:latest not found" when I try to pull | 10:02 |
| locallycompact | ah use the specific tag | 10:02 |
| locallycompact | zenhaskell/analysis:lts-12.9 | 10:02 |
| *** ikerperez has joined #trustable | 10:07 | |
| *** iker has quit IRC | 10:10 | |
| *** willbarnard has joined #trustable | 12:12 | |
| paulsherwood | Shaun: anything to see yet? | 12:25 |
| Shaun | paulsherwood: yes! https://gitlab.com/trustable/autonomous-stpa/tree/control-diagram | 12:28 |
| Shaun | At the moment you'll just get a png of the diagram. I'm adding the losses, hazards, responsibilites etc now then going to add the control actions and get the requirements from then | 12:28 |
| paulsherwood | ok thanks. let's get some 'governance' established | 12:32 |
| paulsherwood | i'll add reviewers + one approval for now | 12:33 |
| Shaun | Thanks. Seems as we have a makefile I'll add a ci file too | 12:33 |
| paulsherwood | ok cool | 12:34 |
| paulsherwood | i guess autonomousvehicles-stpa might be a better name, though... autonomous-stpa hints that the analysis might think for itself :) | 12:35 |
| paulsherwood | or av-stpa | 12:41 |
| paulsherwood | Shaun: ^^ | 12:41 |
| Shaun | good point. av-stpa is less of a... is there a typing equivalent of mouth full? | 12:42 |
| * paulsherwood doesn't believe so | 12:42 | |
| paulsherwood | less to type | 12:43 |
| paulsherwood | or less typing, even | 12:43 |
| *** johnward has quit IRC | 13:01 | |
| *** johnward has joined #trustable | 13:04 | |
| persia | I'm late to the party, but in terms of trust-all-the-way-down, I'd suggest developing a generalised procedure for consuming previously extant code. In such cases, the provenance may lack evidence, but it is worth making assertions about it (e.g. a paragraph talking about why tex is unlikely to be a poor choice), along with writing some requirements (ideally as executable tests) for what we want the tool to do (and not do), such that we can test to | 13:08 |
| persia | ensure that imported changes continue to meet the project needs. | 13:08 |
| flatmush | persia: Do you mean adding comments to buildstream element files? | 13:23 |
| persia | No, although that would be one of many places one could put commentary about imported provenance. | 13:24 |
| persia | More important is having a test suite that says things like "this tool should produce documents this way" or whatever, and running that to show that the selected imported solution is fit for purpose. | 13:24 |
| persia | Whether one runs that once, once for each change to the imported code or dependencies, or as part of some wider CI on every commit is left as a local project decision. | 13:25 |
| persia | My preference would be for a two-tier set of tests: running the tests of teh requirements for the tool on any change to imported code or dependencies, and including use of the tool on CI for projects that related to the tool, such that if the tool doesn't work for a given change, that can be investigated to determine if the change is incompatible with the tool, or if the tool requirements need changing. | 13:27 |
| paulsherwood | Shaun: did you intend to submit a MR, or are you still working on it? | 14:23 |
| Shaun | paulsherwood: Submitted MR for the diagram | 14:26 |
| paulsherwood | tvm | 14:27 |
| paulsherwood | it's a start :-) | 14:34 |
| Shaun | Yes, just a start. I'm going through the rest of the STPA process while reading and learning so it's kind of slow atm but end of next week it will have a lot more detail in :) | 14:37 |
| *** Shaun has quit IRC | 14:44 | |
| paulsherwood | what about the CI? | 14:57 |
| *** willbarnard has quit IRC | 15:04 | |
| *** spinglet has quit IRC | 15:43 | |
| *** ikerperez has quit IRC | 16:03 | |
| *** toscalix has quit IRC | 16:36 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!