| *** toscalix has joined #trustable | 06:06 | |
| *** toscalix has quit IRC | 07:57 | |
| *** sambishop has joined #trustable | 08:27 | |
| *** qwebirc33419 has joined #trustable | 08:46 | |
| *** qwebirc33419 has quit IRC | 08:52 | |
| *** willbarnard_ has joined #trustable | 08:54 | |
| Kinnison | Hi all | 09:20 |
|---|---|---|
| Kinnison | I have been poking at https://gitlab.com/trustable/workflow/blob/master/markdown/roles.md and noticed that the Evidence Tracker doesn't appear to be responsible for t.evidence surrounding t.changes to t.environment or t.requirements | 09:21 |
| Kinnison | Is that intentional? | 09:21 |
| paulsherwood | willbarnard_: ^^ ? | 09:35 |
| willbarnard_ | for t.requirements it should be responsible | 09:37 |
| willbarnard_ | we define t.requirements as a type of t.change | 09:37 |
| * Kinnison would expect t.evidence to be collected for any and all t.changes | 09:37 | |
| willbarnard_ | t.environments are a different case | 09:38 |
| Kinnison | why? | 09:38 |
| paulsherwood | i think Kinnison's point is they shouldn't be different :) | 09:38 |
| willbarnard_ | we consider that t.environments are generated and are ephemeral | 09:38 |
| * Kinnison refers you to https://gitlab.com/trustable/workflow/blob/master/markdown/basics.md#tevidence | 09:38 | |
| Kinnison | t.evidence MUST be produced for each: | 09:38 |
| Kinnison | ... | 09:38 |
| willbarnard_ | we record evidence of there generation in the evidence tracker | 09:39 |
| Kinnison | construction of a t.environment | 09:39 |
| willbarnard_ | yes there is a environment construction evidence type | 09:39 |
| Kinnison | So there's support for it, but the role listed in the roles.md doesn't state the need for it? | 09:40 |
| Kinnison | Sounds like roles.md needs an update | 09:40 |
| willbarnard_ | it is the responsibility of the Orchestrator role to generate the environment construction evidence | 09:41 |
| Kinnison | Right, but https://gitlab.com/trustable/workflow/blob/master/markdown/roles.md#evidence-tracker doesn't state that the evidence tracker is responsible for aggregation and storage of any evidence other than that for t.software | 09:42 |
| Kinnison | Are you stating that the t.requirements and t.environment evidence is included under that umbrella? | 09:42 |
| willbarnard_ | Oh, I understand now what you are saying | 09:43 |
| Kinnison | If so, a clarification in roles.md along the lines of "... which includes, but is not limited to, t.evidence surrounding t.changes to t.software or t.requirements, and t.evidence around the construction of t.environments." would help | 09:43 |
| willbarnard_ | Yes, the evidence tracker is responsible for storing all the 6 types of evidence | 09:43 |
| Kinnison | Otherwise that role looks like it only cares about tracking changes to source code for software | 09:44 |
| willbarnard_ | t.software is different to t.sourcecode | 09:44 |
| * Kinnison also notes that the Gate is responsible only for assessing five of the six kinds of t.evidence | 09:45 | |
| Kinnison | willbarnard_: Okay, that wasn't entirely clear to me | 09:46 |
| Kinnison | in the top of basics.md t.software is defined as being composed of one or more t.changes and having associated t.requirements and t.intents | 09:46 |
| willbarnard_ | the wording could perhaps be a little better, I will see if I can reword it | 09:47 |
| Kinnison | It wasn't clear that t.software is considered to *include* all of t.changes to t.sourcecode and t.changes to t.requirement or t.intents, and the t.evidence around all of that | 09:47 |
| Kinnison | There's just association rather than direct inclusion | 09:47 |
| willbarnard_ | for the role of the gate, the sequence diagram might clarify why it is only the 5 types of evidence | 09:47 |
| Kinnison | which diagram? | 09:48 |
| willbarnard_ | https://gitlab.com/trustable/workflow/blob/master/markdown/change-submission-sequence-diagram.md | 09:48 |
| Kinnison | well that's super-confusing | 09:49 |
| Kinnison | roles.md says the gate is responsible for assessing the t.evidence | 09:50 |
| Kinnison | That diagram suggests the gate is responsible for triggering activity | 09:50 |
| Kinnison | There's no assessment operations in that diagram at all | 09:50 |
| willbarnard_ | The diagram only shows the successful case for brevity | 09:51 |
| Kinnison | There's no assessment going on in the diagram, this confuses me | 09:51 |
| Kinnison | Is the Gate doing anything other than triggering things? | 09:51 |
| Kinnison | The Gate is only delivered two pieces of data in that diagram (validation result, and policy handling result) | 09:52 |
| Kinnison | and does nothing apparent with them | 09:52 |
| willbarnard_ | in the unsuccessful case the ci pipeline will fail and terminate | 09:55 |
| willbarnard_ | if we want to show those cases we would need a whole set of diagrams | 09:55 |
| * Kinnison fears he's not being quite clear in his concern | 09:55 | |
| Kinnison | The Gate is responsible for *assessing* t.evidence | 09:56 |
| Kinnison | That diagram shows only t.evidence being logged | 09:56 |
| Kinnison | not being assessed | 09:56 |
| Kinnison | Therefore, while it may be valuable in its own right, it does not tell me why the Gate is responsible only for five of the six kinds of t.evidence | 09:56 |
| willbarnard_ | I would be happy to change the term assessing | 09:57 |
| Kinnison | What would you change it to? | 09:57 |
| willbarnard_ | Do you have a suggestion? | 09:58 |
| Kinnison | No, because I have no idea what Gate is properly doing | 09:58 |
| Kinnison | I am entirely confused | 09:58 |
| willbarnard_ | The final step is change review evidence. The reviewer is responsible for review and approval. | 10:00 |
| Kinnison | The diagram shows the 'Gate' responding to a change by triggering a series of what I would consider pipeline steps in a CI | 10:00 |
| willbarnard_ | exactly | 10:00 |
| Kinnison | roles.md states that the Gate *assesses* evidence | 10:00 |
| Kinnison | to assess is to examine and to ascribe *value* | 10:00 |
| Kinnison | So either the diagram needs to show that, or the role description is incorrect | 10:01 |
| willbarnard_ | I would be happy to change the term assessing | 10:01 |
| Kinnison | synonyms for 'assess' include 'measure' 'evaluate' 'appraise' 'value' 'classify' etc. | 10:02 |
| Kinnison | Is the Gate doing anything like that? | 10:02 |
| * Kinnison worries that he's either missing something critical, or just not communicating well enough :( | 10:04 | |
| paulsherwood | a gate doesn't just assess, it opens/closes iiuc | 10:14 |
| * Kinnison nods, hence my confusion. In the diagram, 'Gate' is acting as a CI pipeline controller | 10:14 | |
| Kinnison | Essentially like gitlab-runner | 10:15 |
| * Kinnison goes for a walk to see if inspiration hits | 10:15 | |
| persia | Without certainty on how much semantics may have changed, some time ago "gate" was mapped to https://docs.openstack.org/infra/zuul/user/gating.html | 10:18 |
| persia | Summary being something that performs the act of automerge based on some set of policy-defined criteria | 10:19 |
| persia | https://zuul-ci.org/docs/zuul/user/gating.html seems to be the more modern URL for that, actually | 10:22 |
| willbarnard_ | in the case that the triggered actions return a "fail" result, e.g. the artefact construction, change validation or policy check fail then the Gate will not proceed to the next step | 10:25 |
| paulsherwood | willbarnard_: quite... so we need something other than 'assess' | 10:26 |
| persia | That suggests semantics have changed, as the earlier semantics did not impose serialised "steps" prior to gate processing (although any imposed gate did serialise state progression through a complex flow). | 10:27 |
| persia | (also, insert "artefact" vs, "artifact" rant related to the silliness of copying poor international decisions in an attempt to differentiate national origin of language) | 10:28 |
| paulsherwood | willbarnard_: eek... did i break the build? | 13:43 |
| paulsherwood | https://gitlab.com/trustable/gitect/-/jobs/76523154 | 13:43 |
| willbarnard_ | paulsherwood: it looks like there is a missing except: master in the ci file | 13:46 |
| *** willbarnard_ has quit IRC | 15:46 | |
| *** sudonym has joined #trustable | 15:54 | |
| *** weyfonk has joined #trustable | 15:55 | |
| *** weyfonk has quit IRC | 17:07 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!