IRC logs for #trustable for Tuesday, 2017-01-10

*** AlisonChaiken has quit IRC03:45
*** ctbruce has joined #trustable08:27
*** LaurenceUrhegyi has joined #trustable08:35
*** toscalix has joined #trustable08:59
*** mdunford has quit IRC09:06
*** mdunford has joined #trustable09:06
*** mdunford has quit IRC09:33
*** persia has quit IRC09:39
*** dabukalam has quit IRC09:39
*** persia has joined #trustable09:39
*** dabukalam has joined #trustable09:40
*** mdunford has joined #trustable09:48
*** mdunford has quit IRC09:54
*** mdunford has joined #trustable09:54
*** locallycompact has joined #trustable11:45
* paulsherwood notices that the page history link on is not working12:55
paulsherwoodchrispolin: but more importantly.... the diagram now looks like this is all about development12:56
paulsherwoodi can quite see why andrew said he is HUGELY concerned12:56
rjekpage works for me, too12:56
paulsherwood 404 on two different browsers12:57
rjekIs the 404 from GitLab?12:59
chrispolinpaulsherwood, yes, I agree. It has shifted quite a bit from the original idea, although I'm not sure we have put a lot of thought into a 'trustable' means of gathering requirements/design etc as yet. More thought required.12:59
paulsherwoodchrispolin: tests need to be derived from requirements and standards. test results are needed to demonstrate that requirements and standards are met13:01
paulsherwoodin the meantime, please reply to andrew :)13:01
paulsherwoodand fix your text: there's no way the subset you've described 'details a model workflow for software that can be considered 'Trustable'' yet13:02
chrispolinNoted, will do.13:02
jmacspaulsherwood: You need to be logged into GitLab, for some reason13:03
chrispolinI had assumed that was only an issue for private/internal projects.13:03
paulsherwoodjmacs: ack, thanks13:04
chrispolinAh, internal projects 'can be cloned by any logged in user' (as opposed to public projects which don't require any authentication). Doesn't mention viewing page history.13:09
jmacsAny reason we shouldn't make it public?13:12
chrispolinIt is public.13:12
chrispolinThe distinction between public and internal is whether authentication is required to clone the repo, rather than view the edit history. That must be universal.13:13
chrispolinSeems remiss of Gitlab not to mention that somewhere.13:13
jmacsSeems illogical.13:13
paulsherwoodseems like a bug, to me13:13
*** LaurenceUrhegyi has quit IRC13:40
*** LaurenceUrhegyi has joined #trustable13:47
*** mdunford has quit IRC14:31
*** mdunford has joined #trustable14:46
*** mdunford has quit IRC15:43
*** mdunford has joined #trustable15:43
persiaSo, based on some of the feedback to the diagram, and an episode of writer's block, I ended up changing all the characters for the first couple stories.  I don't think a final mustard should be arranged this way, but for now, I've put everything in one file for easy sharing, and pasted to
persiaBefore I start exploring further (implementation, deployment, etc.), or considering more complicated failure cases, I wanted to confirm that others thought the format was sensible, and that the initial behaviours I have described match a shared understanding.15:48
*** ctbruce has quit IRC15:56
chrispolinHaving a read now.16:07
LaurenceUrhegyiIt would be useful, I think, to discuss some of the main issues raised on the mailing list before delving into the stories.16:10
persiaLaurenceUrhegyi: If you like.  My thought was that the description we had was confusing, and that writing it differently as stories would be useful.16:14
persiaAre there any particular points you want to raise from the feedback?16:14
LaurenceUrhegyipersia: well, it is important that chrispolin responds to the mailing list today, but I get the impression (please do tell me if i'm wrong here) that chrispolin doesn't feel completely comfortable with how to respond yet16:17
LaurenceUrhegyiand what I mean by that is that there are clearly some elements missed from the model, and it'd be good to iron them out here so we're clear at a high level what they are and what they mean.16:19
persiaMy read of the discussion is that the material presented did not include enough information for the recipients to see the point.  While the points can be argued, I would expect the easier solution would be to apparently capitulate, and rewrite things to be in a more comprehensible form.16:21
LaurenceUrhegyiI understand that16:21
LaurenceUrhegyibut it will take us all week16:21
LaurenceUrhegyiif nothing else, we need to be able to respond to Edmund and Andrew effectively, as the radio silence is not good.16:21
persiaVery quickly, I think role definition belongs in a standard, and that trustable should allow any role definition that makes sense for a project.  I don't forsee any need for a standard encoding for standards, as long as they can be machine-readable in a way that allows one to test compliance on a per-project basis.16:22
persiaWhile some organisations have firm role arrangements, others have more flexible roles, and I assert that this depends on the standards with which they must comply.  The provided document specifically indicates that any changes are tested against standards before merge, and that compliance documentation is delivered with deployment, so I'm not sure which parts of compliance verification or continuous compliance are missing.  The display style needs16:24
persiaThe workflow is specifically intended to apply to analysts, designers, architects, developers, and everyone else, although perhaps this wasn't made clear.16:24
persiaBased on that, I suspect the text needs to be replaced with audience-accessible text, and that the diagram should probably be scrapped, as the individual components and/or roles in that diagram likely imply specific limited activities to some of the audience.16:26
paulsherwoodwe still (desperately) need a diagram (or several)16:27
persiaI agree that presenting it in a more accessible manner will take some time: perhaps that is the appropriate response to the comments.16:27
LaurenceUrhegyiperhaps, yes16:27
persiaBecause I think few people respond well to being told that they missed something, especially when that thing isn't made entirely clear.16:28
persiaMots concerning to me is that there are two respondees that seem to think this is only a developer workflow, which I suspect is due to the label "developer" on the diagram being taken to mean "someone who spends time coding", rather than "someone who creates or alters something".16:29
persiapaulsherwood: I think we probably need several diagrams.  From discussions last week, I had the impression that we didn't have a good consensus on who was using the system, or for what, hence the stories.16:29
persiaGiven stories, I think we should be able to create sensible sequence diagrams showing the various ways in which things are done.16:30
persiaPart of why I changed the Personas so that Alice&Bob were not developers was to reduce the impression that this was developer-centric.  Having early-named characters with different business roles helps folk concentrate on the non-developer workflows.16:31
* paulsherwood gently suggests returning to something like the original diagram at top-level, and then doing sequence or other more accurate representations for the details16:33
persiaAs a quick fix to the current diagram, does anyone think changing "Developer" to "Creator" or "Author" would make it appear less development-specific?16:34
paulsherwoodnope - doesn't address andrew's comments16:34
persiaI read Andrew's comments as simply "You labeled this 'Developer', so it must mean you are ignoring all the things I don't consider 'Developer'".  What did I miss?16:35
persiapaulsherwood: On the "original diagram": do you mean something like ?16:37
paulsherwoodbecause it at least emphasises requirements, standards, tests .. but still misses architecture completely :)16:38
paulsherwoodthe current diagram only mentions requirements in a commment...16:38
paulsherwood'testing seems an afterthought' - no flow from requirements to tests16:38
chrispolinI think this was the last iteration of that particular diagram:
persiaThe current diagram was an evolution of that, based on attempts to identify the components, and fix things like CD producing code (vs. code as input to patch review).16:41
persiaMaybe basing a revision on a component diagram was the wrong direction, and it would have made more sense to base it on a sequence diagram or activity diagram, to show how standards inform requirements inform code, etc.16:41
paulsherwoodchrispolin: i'd go with that... but try to figure out how architecture fits into it :)16:42
persiaI think it will be more consumable as two diagrams.  A sequence or actiity diagram to show how the pieces inform each other, and a component diagram for the architecture.16:44
persiaBecause I expect that most folk will want to use the same tooling to manage their standards, requirements, testing, code, etc.16:44
paulsherwood+1 for multiple diagrams16:44
chrispolinI would agree.16:45
paulsherwoodpersia: btw i'm happy with your example stories16:46
persiapaulsherwood: Thanks for the confirmation.16:47
chrispolinWould you be happy to have the link included in my response to the mailing list persia?16:49
persiachrispolin: Which link?  The link to my paste?  Sure, as long as you mention that it's draft.  I already noticed that the interaction between Felix and Alice was supposed to be an interaction between Felix and Claire.16:50
persiaThe link to the old diagram?  That's fine by me as well.16:50
chrispolinI'll be sure to make that clear. No sorry, the link to the user stories paste.16:50
persiaBut I think the key factor is that more diagrams are needed, and that the first diagram is purely architectural.16:50
persiaI think we need an activity diagram showing standards, requirements, etc.16:51
chrispolinI think both diagrams need to be reconciled with each other before posting them, so I'll take a bit of time to revisit the activity diagram (and write it into UML).16:51
persiaMostly because  sequence diagram requires more details, so I expect it to be harder to create.16:58
*** LaurenceUrhegyi has quit IRC17:16
rjekOnly vaguely related, but I was reminded by the existance of Mark D. Wooding recently, and reading was interesting, specifically how trust and his licence choice interacted17:20
persiarjek: That's a good argument for source access, but I don't think that  A) trust requires a specific license, B) bugs are necessarily quickly found from public source (e.g. DSA-1571-1), or C) an organisation with source access to vendors is subject to the need for library recompilation validation.17:45
rjekpersia: I think for A) he is ideologically aligned with the GPL but still feels trust is more import than that ideology17:48
rjekWhich I felt was the interesting part17:49
rjek(Rather than the attack itself)17:49
persiaYes, and that LGPL encourages wider use of his (possibly trusted) library, with recompilation verification protection available to end-consumers who do not have source access to intermediate library clients.17:50
*** LaurenceUrhegyi has joined #trustable17:52
persiaYAML format example for G/W/T encoding in stories in Mustard: - does anyone think that needs to be shown differently?  Is there a need to differentiate different vcrit categories for G/W/T vs. UML vs. BNF, etc.?17:52
* rjek nods17:52
jmacsNo... to be totally sure, we could add a 'description-encoding' field to the vcrit, but I think it will be reasonable just to detect the different formats17:54
persiajmacs: You mean to rely on the consuming tool to recognise the formats, and test appropriately?17:57
persiaAlthough, reading more about testing (e.g. Arrange, Act, Assert), perhaps even things in UML or BNF could be wrapped in G/W/T.17:58
*** AlisonChaiken has joined #trustable17:59
jmacsIsn't the whole point of G/W/T that it's human-readable? UML source text really isn't.17:59
persiaBut the implementation details of tooling to consume requirements in YAML and perform appropriate validation is something I'm happy to defer, and I think format-detection isn't so complicated as to be unworkable.18:00
persiaUML source isn't particularly human-readable, but it's fairly trivial to render, and the diagrams are expected to be human-readable.18:02
persiaSo, if a project wants to express requirements, architecture, or design in UML, I would expect that the YAML renderer would be able to render the diagrams for consumption by humans, and that the CI system would be able to parse the source format to prepare tests (and/or generate code).18:02
persia(or maybe some other tooling, used by the CI system to inform test selection, etc.)18:03
jmacsThat sounds quite difficult in practice, but possible.18:03
persiaWhich part is difficult?18:03
jmacsGenerating tests from UML documents that are also requirements18:04
persiaI had the impression the TextUML Toolkit contained some facilities to validate that implementation code complied with a given UML diagram, but reading more closely, this may only be format validtion for the UML source.18:06
persia claims that AGAPE can do this for Eclipse's UML2 format (which is frustratingly not easily generated by humans, although conversion from some other diagram specification format to EUML2 automatically should be feasible)18:10
*** toscalix has quit IRC18:12
persia may also be relevant18:16
*** locallycompact has quit IRC18:21
*** LaurenceUrhegyi has quit IRC19:55
*** AlisonChaiken has quit IRC21:34
*** AlisonChaiken has joined #trustable21:43

Generated by 2.14.0 by Marius Gedminas - find it at!