| *** AlisonChaiken has quit IRC | 03:45 | |
| *** ctbruce has joined #trustable | 08:27 | |
| *** LaurenceUrhegyi has joined #trustable | 08:35 | |
| *** toscalix has joined #trustable | 08:59 | |
| *** mdunford has quit IRC | 09:06 | |
| *** mdunford has joined #trustable | 09:06 | |
| *** mdunford has quit IRC | 09:33 | |
| *** persia has quit IRC | 09:39 | |
| *** dabukalam has quit IRC | 09:39 | |
| *** persia has joined #trustable | 09:39 | |
| *** dabukalam has joined #trustable | 09:40 | |
| *** mdunford has joined #trustable | 09:48 | |
| *** mdunford has quit IRC | 09:54 | |
| *** mdunford has joined #trustable | 09:54 | |
| *** locallycompact has joined #trustable | 11:45 | |
| * paulsherwood notices that the page history link on https://gitlab.com/trustable/overview/wikis/TrustableSoftwareWorkflow is not working | 12:55 | |
| chrispolin | WFM? | 12:55 |
|---|---|---|
| paulsherwood | 404 | 12:56 |
| paulsherwood | chrispolin: but more importantly.... the diagram now looks like this is all about development | 12:56 |
| paulsherwood | i can quite see why andrew said he is HUGELY concerned | 12:56 |
| rjek | page works for me, too | 12:56 |
| paulsherwood | https://gitlab.com/trustable/overview/wikis/TrustableSoftwareWorkflow/history 404 on two different browsers | 12:57 |
| rjek | Is the 404 from GitLab? | 12:59 |
| chrispolin | paulsherwood, 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 |
| paulsherwood | chrispolin: tests need to be derived from requirements and standards. test results are needed to demonstrate that requirements and standards are met | 13:01 |
| paulsherwood | in the meantime, please reply to andrew :) | 13:01 |
| paulsherwood | and fix your text: there's no way the subset you've described 'details a model workflow for software that can be considered 'Trustable'' yet | 13:02 |
| chrispolin | Noted, will do. | 13:02 |
| jmacs | paulsherwood: You need to be logged into GitLab, for some reason | 13:03 |
| chrispolin | I had assumed that was only an issue for private/internal projects. | 13:03 |
| jmacs | ¯\_(ツ)_/¯ | 13:04 |
| paulsherwood | jmacs: ack, thanks | 13:04 |
| chrispolin | Ah, 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 |
| jmacs | Any reason we shouldn't make it public? | 13:12 |
| chrispolin | It is public. | 13:12 |
| jmacs | Oh. | 13:12 |
| chrispolin | The 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 |
| chrispolin | Seems remiss of Gitlab not to mention that somewhere. | 13:13 |
| jmacs | Seems illogical. | 13:13 |
| paulsherwood | seems like a bug, to me | 13:13 |
| chrispolin | Probably. | 13:14 |
| *** LaurenceUrhegyi has quit IRC | 13:40 | |
| *** LaurenceUrhegyi has joined #trustable | 13:47 | |
| *** mdunford has quit IRC | 14:31 | |
| *** mdunford has joined #trustable | 14:46 | |
| *** mdunford has quit IRC | 15:43 | |
| *** mdunford has joined #trustable | 15:43 | |
| persia | So, 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 http://paste.baserock.org/fulidaziwu | 15:46 |
| persia | Before 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 IRC | 15:56 | |
| chrispolin | Having a read now. | 16:07 |
| LaurenceUrhegyi | It would be useful, I think, to discuss some of the main issues raised on the mailing list before delving into the stories. | 16:10 |
| persia | LaurenceUrhegyi: 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 |
| persia | Are there any particular points you want to raise from the feedback? | 16:14 |
| LaurenceUrhegyi | persia: 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 yet | 16:17 |
| LaurenceUrhegyi | and 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 |
| persia | My 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 |
| LaurenceUrhegyi | I understand that | 16:21 |
| LaurenceUrhegyi | but it will take us all week | 16:21 |
| LaurenceUrhegyi | if nothing else, we need to be able to respond to Edmund and Andrew effectively, as the radio silence is not good. | 16:21 |
| persia | Very 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 |
| persia | While 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 needs | 16:24 |
| persia | work. | 16:24 |
| persia | The workflow is specifically intended to apply to analysts, designers, architects, developers, and everyone else, although perhaps this wasn't made clear. | 16:24 |
| persia | Based 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 |
| paulsherwood | we still (desperately) need a diagram (or several) | 16:27 |
| persia | I agree that presenting it in a more accessible manner will take some time: perhaps that is the appropriate response to the comments. | 16:27 |
| LaurenceUrhegyi | perhaps, yes | 16:27 |
| persia | Because I think few people respond well to being told that they missed something, especially when that thing isn't made entirely clear. | 16:28 |
| persia | Mots 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 |
| persia | paulsherwood: 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 |
| persia | Given stories, I think we should be able to create sensible sequence diagrams showing the various ways in which things are done. | 16:30 |
| persia | Part 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 details | 16:33 | |
| persia | As 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 |
| paulsherwood | nope - doesn't address andrew's comments | 16:34 |
| persia | I 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 |
| persia | paulsherwood: On the "original diagram": do you mean something like https://gitlab.com/trustable/overview/wikis/TrustableSystemStructure ? | 16:37 |
| paulsherwood | yes | 16:37 |
| paulsherwood | because it at least emphasises requirements, standards, tests .. but still misses architecture completely :) | 16:38 |
| paulsherwood | the current diagram only mentions requirements in a commment... | 16:38 |
| paulsherwood | 'testing seems an afterthought' - no flow from requirements to tests | 16:38 |
| chrispolin | I think this was the last iteration of that particular diagram: https://gitlab.com/trustable/overview/wikis/TrustableSoftwareWorkflow?version_id=564be393413f2f71a79e1bc91b62c7248f2ef336 | 16:40 |
| persia | The 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 |
| persia | Maybe 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 |
| paulsherwood | chrispolin: i'd go with that... but try to figure out how architecture fits into it :) | 16:42 |
| persia | I 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 |
| persia | Because 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 diagrams | 16:44 |
| chrispolin | I would agree. | 16:45 |
| paulsherwood | persia: btw i'm happy with your example stories | 16:46 |
| persia | paulsherwood: Thanks for the confirmation. | 16:47 |
| chrispolin | Would you be happy to have the link included in my response to the mailing list persia? | 16:49 |
| persia | chrispolin: 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 |
| persia | The link to the old diagram? That's fine by me as well. | 16:50 |
| chrispolin | I'll be sure to make that clear. No sorry, the link to the user stories paste. | 16:50 |
| persia | But I think the key factor is that more diagrams are needed, and that the first diagram is purely architectural. | 16:50 |
| persia | I think we need an activity diagram showing standards, requirements, etc. | 16:51 |
| chrispolin | I 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 |
| persia | Mostly because sequence diagram requires more details, so I expect it to be harder to create. | 16:58 |
| *** LaurenceUrhegyi has quit IRC | 17:16 | |
| rjek | Only vaguely related, but I was reminded by the existance of Mark D. Wooding recently, and reading http://www.chiark.greenend.org.uk/ucgi/~mdw/git/catacomb/blob/HEAD:/README was interesting, specifically how trust and his licence choice interacted | 17:20 |
| persia | rjek: 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 |
| rjek | persia: I think for A) he is ideologically aligned with the GPL but still feels trust is more import than that ideology | 17:48 |
| rjek | Which I felt was the interesting part | 17:49 |
| rjek | (Rather than the attack itself) | 17:49 |
| persia | Yes, 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 #trustable | 17:52 | |
| persia | YAML format example for G/W/T encoding in stories in Mustard: http://paste.baserock.org/yowurujoda - 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 nods | 17:52 | |
| jmacs | No... 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 formats | 17:54 |
| persia | jmacs: You mean to rely on the consuming tool to recognise the formats, and test appropriately? | 17:57 |
| jmacs | yes | 17:58 |
| persia | Although, 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 #trustable | 17:59 | |
| jmacs | Isn't the whole point of G/W/T that it's human-readable? UML source text really isn't. | 17:59 |
| persia | But 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 |
| persia | UML source isn't particularly human-readable, but it's fairly trivial to render, and the diagrams are expected to be human-readable. | 18:02 |
| persia | So, 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 |
| jmacs | That sounds quite difficult in practice, but possible. | 18:03 |
| persia | Which part is difficult? | 18:03 |
| jmacs | Generating tests from UML documents that are also requirements | 18:04 |
| persia | I 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 | http://www.drdobbs.com/architecture-and-design/test-case-generation-uml-and-eclipse/211600996 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 IRC | 18:12 | |
| persia | https://wiki.eclipse.org/Papyrus_Developer_Guide/Automatic_Test_Generation_for_Diagram_Editors may also be relevant | 18:16 |
| *** locallycompact has quit IRC | 18:21 | |
| *** LaurenceUrhegyi has quit IRC | 19:55 | |
| *** AlisonChaiken has quit IRC | 21:34 | |
| *** AlisonChaiken has joined #trustable | 21:43 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!