| *** AlisonChaiken has joined #trustable | 03:51 | |
| *** AlisonChaiken has quit IRC | 07:12 | |
| *** AlisonChaiken has joined #trustable | 07:13 | |
| *** ctbruce has joined #trustable | 08:27 | |
| *** tiagogomes has joined #trustable | 09:26 | |
| *** ctbruce has quit IRC | 09:56 | |
| *** ctbruce has joined #trustable | 10:04 | |
| *** laurenceurhegyi has joined #trustable | 10:44 | |
| *** persia has quit IRC | 11:07 | |
| *** persia has joined #trustable | 11:09 | |
| *** ctbruce has quit IRC | 11:52 | |
| *** ctbruce has joined #trustable | 12:04 | |
| ChrisPolin | I have updated the wiki entry to incorporate the deployment methods into the Trustable workflow. (https://gitlab.com/trustable/overview/wikis/TrustableSystemStructure) | 14:03 |
|---|---|---|
| ChrisPolin | I've still to update the UML (components -> Activities), its next on the list. | 14:03 |
| ChrisPolin | Let me know what you think of the updated model. | 14:03 |
| ChrisPolin | (nipping out for half an hour to grab lunch, so I'll be afk for a bit.) | 14:04 |
| persia | To my mind, an automerger usually operates on source code repos, consuming patches from a patch tracker, and injecting them into some consumable mainline. | 14:05 |
| persia | For the text, I don't understand the phrase "reports what downstream changes it is responsible for". | 14:05 |
| ChrisPolin | Perhaps that arrow should come from the CI component, rather than the test artifacts one. | 14:06 |
| persia | This is part of the problem with conflating component and activity diagrams :) | 14:06 |
| ChrisPolin | Noted. I was referring to what behavioural changes the patch may invoke, although perhaps this may be unnecessary. | 14:07 |
| persia | The "thing-that-is-done" is not necessarily easily associated with the "thing-that-does-things". | 14:07 |
| ChrisPolin | Mm, I'm beginning to learn that! | 14:07 |
| persia | Heh, anyway, enjoy your lunch. I'll read deeper, and see if I can provide a more useful critique this afternoon. | 14:08 |
| ChrisPolin | Thanks, let me know your thoughts. | 14:08 |
| paulsherwood | ChrisPolin: it's starting to look more like an elephant :) | 14:43 |
| paulsherwood | title is still wrong... s/Trustablesystemstructure/something better/ please | 14:44 |
| paulsherwood | ChrisPolin: istm your Code box is not really code, it should be system, or instance or target or something? | 14:45 |
| paulsherwood | Code to me implies source, and should be somewhere below Patch Review, above CI | 14:46 |
| persia | As I try to diagram things, I wonder if I'm thinking about the same problem as others. Does http://www.plantuml.com/plantuml/png/VP71JiCm38RlUGeVjrTW1mJb00SaDFO2NkEr4MbS4cSxJBmxNjAE8atBASh_sVxzvy3nou2UXq_1O37Q14sFeQEqqVU3oe0Tkb2XBNrd5scW87UvXYqjTGgsCCQSUkS9Lf6EZaxGLkHn3Ix1Ah30GB4Zt7jQcwblxVYQ1momBMKt9euOnOdZ04zPU40XMrau5rqxl5ywGwDREglwF1k4OOSg2Jn736s_cGi-8jlSBaiQ7aRl529rCdAKE-oEaYYLifTKiPz_GUXjocAvykHIFRtGaJoFbwYlninrpbAzuUeFV5Ej_1UMTFIN9QUP-mK0 | 14:46 |
| persia | look sensible? | 14:46 |
| persia | Note that when I'm trying to think in terms of "thing-that-is-done", none of CI system, CD system, Patch Tracker, Repo, etc. exist. | 14:48 |
| persia | (as those are nouns) | 14:48 |
| paulsherwood | before i think about that, did you generate it via an api at platuml.com? | 14:48 |
| persia | Yes. | 14:53 |
| persia | But it's not a very interesting API. One loads a given page, submits text in a form, processes the form, and then screen-scrapes a URL. | 14:53 |
| persia | It is likely one could cache the initial form, so just submit something, then process the response for a URL, if you're thinking something javascripty to embed somewhere. | 14:54 |
| persia | The URL itself is another API, although I haven't found documentation for it: it compresses the plantUML text into the querystring, so that the plantUML server can generate it on demand. | 14:55 |
| persia | Actually, seems PlantUML publish the javascript to generate the magic URL in the source of the editor page, as the "compress" function. | 14:58 |
| persia | (the core bit being `encode64(zip_deflate(string));`: if one replaces "string" with the textual data, one ends up with the magic string for the generator URL. | 15:00 |
| *** ctbruce has quit IRC | 15:01 | |
| jmacs | If we could put arbitrary javascript into our pages, we might as well render the UML in javascript ourselves | 15:01 |
| persia | If you cannot, almost no API will help, sadly. | 15:04 |
| jmacs | I don't think it'll be possible with the public instance of gitlab. | 15:06 |
| persia | I can believe that for gitlab-hosted pages. Would it make sense to have another service consume a git repo containing the content, and render it there? | 15:07 |
| jmacs | You could theoretically repeatedly pull the git repo and render images out of it | 15:07 |
| jmacs | Assuming gitlab allows remote URLs for images, which I might test now | 15:08 |
| persia | Assuming remote URLs for images is permitted, if the PlantUML is in the same repo as the content showing the diagram, you could also set up a pre-commit hook that generated the right URL string and didn't allow the commit unless the image reference matched. | 15:09 |
| persia | That makes the results all static, although it might be a little frustrating for committers. | 15:09 |
| jmacs | Yes, you can embed remote images in a gitlab wiki. | 15:11 |
| jmacs | Shall I try and set that up? | 15:12 |
| persia | The git hook? | 15:12 |
| jmacs | The whole rendering service | 15:13 |
| persia | I was hand-waving a bit when I described it. There would need to be a known set of sources that were supposed to be pre-processed, and some means of tagging what URLs needed to be generated, etc. | 15:13 |
| persia | Oh, if you think you can do a full rendering service without it being as kludgey as I just described, I suspect I might use it if I wanted to submit UML to the wiki. | 15:13 |
| jmacs | I think I can do that. | 15:14 |
| persia | My ideal interface would be some mechanism to reference the filename of the UML in an <img> tag, but the only way that I would know how to do that is with arbitrary javascript, which complicates things. | 15:14 |
| persia | http://www.plantuml.com/plantuml/uml/ is the base page of the plantUML site, from which one is redirected to a session-aware page with pre-populated UML, the source of which contains the javascript functions they use. | 15:16 |
| jmacs | Ideally I'd like inline UML in wiki pages, which means hiding the UML from the browser | 15:16 |
| persia | For that, you need pre-processing. | 15:17 |
| persia | Actually, you could also do javascript post-processing with DOM tricks and hidden DIVs, but that's more likely to run into issues if there are limitations for arbitrary javascript. | 15:18 |
| jmacs | ChrisPolin: Could you send me the UML source for your diagram? | 15:29 |
| ChrisPolin | paulsherwood, if it's big and grey etc. I was going to change the page name but I can't see a straightforward way of doing so on gitlab without just creating a new page and removing the old one. If you're happy enough to lose the edit history then I'll go ahead and do that now. | 15:30 |
| persia | jmacs: It's in the repo, as TSS?UML | 15:30 |
| persia | Err, TSS_UML | 15:30 |
| ChrisPolin | Oop, I haven't updated the repo, hang on. | 15:30 |
| ChrisPolin | And ack re: 'code', I'll fix that too. | 15:31 |
| persia | That's the strongest argument for inline UML in the wiki :) | 15:31 |
| jmacs | persia, ChrisPolin: Got it, thanks | 15:31 |
| persia | Updates to the draft above, after which I'll stop until/unless someone tells me that I'm solving the same problem: http://www.plantuml.com/plantuml/png/VPBFRi8m3CRlVGeVool0OMA0j1sOAk2oezMuRRGswHA7FvhsxdEQmZeDqLEKxsVxyvTMrdra8DzypsWKEkLXrQ2foI_alX8Pi4Pj4hIZpw0TTMJu8RUoYgOw6JKmMNPgT4kGRydLGZZDv3J2blXf1jf3_cPdsTWmjNe97HhOqL7JwSwe7XrhrjR0Ch3ja4ab5hu6NJgCisGzhKI7Cla2jd10aHYU7PgoMLmB2cTLAASbAzlrhHQ8n4bl7JzW3-HPA1zQzWdx_fE0dCOGtidBigC_SREc8xMsZ- | 15:37 |
| persia | dUB6Mt2LFrZfzVy5MquObmo4KUbeE_moqbkGhBw3ARRyvK1d6_EVTal3wcFRIfHTGLvF_keK3lISs06pAGN-8kapps-o8kFrzJtzfBt2ufqL8K536MJKQjbo2C7MgJHU0OO8Mw3IxzFLTM4gv-0000 | 15:37 |
| ChrisPolin | That's the updated version now (pre-changes as per Paul's suggestion) | 15:37 |
| ChrisPolin | Oops, link breaker! Sorry persia! | 15:37 |
| persia | Link breaker? | 15:37 |
| persia | Did my text run over your buffer? | 15:38 |
| ChrisPolin | Ah it did, and I posted in the middle of it lol. | 15:38 |
| persia | Oops. I can paste again, if that would help. | 15:38 |
| ChrisPolin | Got it now. | 15:39 |
| persia | If that is the right path, there are more loops needed, more parallelism, and some of the labels probably have to change, but I worry that it moves far enough away from concrete systems to be confusing. | 15:49 |
| ChrisPolin | persia: I can see the distinction between activity and component that you're making. I would argue that, given the approach that you've taken with yours, the diagram I made should be made *more* component-oriented. | 16:36 |
| paulsherwood | ChrisPolin: nearly there. can/should there be a box for code between patch review and continuous integration? | 16:38 |
| ChrisPolin | Yep, can do that. Although should the code go before or after patch review? | 16:38 |
| ChrisPolin | To my mind, the code is submitted to review. | 16:38 |
| paulsherwood | to my mind code is a collection of patch reviews | 16:39 |
| ChrisPolin | Mm, fair enough. Will add now. | 16:40 |
| paulsherwood | s/patch reviews/patches, preferably reviewed/ | 16:40 |
| ChrisPolin | Updated. | 16:42 |
| ChrisPolin | The elephant is getting taller. | 16:42 |
| persia | I'm not seeing the latest update (wiki claims it was updated 2 hours ago), but I'm not sure I understand the intent of the proposed change. | 16:43 |
| persia | ChrisPolin: Ah, so you're thinking that we don't want an activity diagram, but instead want a component diagram? | 16:44 |
| ChrisPolin | I think it gives the reader a bit more to bite into. The activity-oriented approach is, to my mind, a little too abstract. | 16:46 |
| persia | That was my concern, but paulsherwood seems to be encouraging more use of verbs, and less description of infrastructure. | 16:46 |
| persia | I am not convinced that both activities and structure can be described in the same UML diagram, if that diagram is intended to be machine-parseable. | 16:47 |
| ChrisPolin | Lol I was just typing the same thing. They tell the same story, but I'm thinking more from a reader perspective. | 16:48 |
| persia | Anyway, I promised you a detailed review of the text, which I never sent. | 16:48 |
| ChrisPolin | Perhaps my approach is not the correct way to look at it. | 16:48 |
| persia | First paragram is clear. | 16:48 |
| persia | Second Paragraph: | 16:48 |
| persia | 1) Should G/W/T be an example? Is there an expectation that UML will also be acceptable (assuming it can be machine-tested)? | 16:49 |
| persia | 2) Same applies to "BDD tools", really. | 16:50 |
| persia | 3) The last sentence doesn't appear to have any referent (specifically "this metadata" doesn't seem to attach to any previous use of the word "metadata") | 16:50 |
| persia | Third Paragraph: | 16:50 |
| persia | 1) How does the patch review system trace to a developer? Signed Commits? Authenticated-push? Trust of the VCS assertions? | 16:51 |
| persia | 2) How is a scenario linked to a line of code? Is this developer discretion + human review? (consider the example where code that implements something doesn't happen to be in the same commit as code that enables that codepath) | 16:52 |
| persia | 3) Why are test results a standalone artifact? I would expect to find them linked from the patch review system. | 16:52 |
| persia | Fourth paragraph is sensibly, modulo the G/W/T note from the second paragraph | 16:52 |
| persia | s/sensibly/sensible/ | 16:52 |
| *** ctbruce has joined #trustable | 16:53 | |
| persia | The fifth paragraph seems to have some assumptions I don't understand. I'd need to be walked through it to be able to critique it beyond "I don't understand this". | 16:53 |
| ChrisPolin | Detailed indeed, thank you! To take your points in turn: | 16:54 |
| ChrisPolin | First paragraph: Good start! =) | 16:54 |
| ChrisPolin | Second paragraph: 1) and 2) - This is not my area of expertise (yet) so I'm very open to suggestion. From my reading, G/W/T and BDD seem to be a very convenient way to link requirements and tests relatively directly. I should perhaps include a caveat that the overall trustable model does not exclusively function on the BDD approach. | 16:55 |
| ChrisPolin | 3) Noted. I was referring to the requirements in the yaml file referenced in the first paragraph, but I will clarify this. | 16:56 |
| persia | I agree that they are convenient, but from our discussion Monday, I had the impression that it made sense to step back one layer of abstraction, so that Trustable was only asserting that requirements be A) human comprehensible and B) machine testable, without specifying the workflow for the project, any specific formats, etc. | 16:57 |
| persia | Ah, that's the difference then. I consider "requirements" to be core data, preferably in a repo (ideally not the same repo as the code repo), so not metadata. | 16:57 |
| jmacs | Why not in the same repo? | 16:58 |
| persia | jmacs: Mostly to make it easier to review/stage changes to requirements separately from changes to code. This may be an implementation concern. | 16:58 |
| persia | My past experience with projects that have requirements & code in the same repo has been that they will sometimes change in concert without anyone noticing. | 16:59 |
| persia | My experience with projects that separate the requirements from the code is that it becomes easy to have additional roles that might be part of the reviewers for the requirements changes, but are not trusted to be reviewers for the code changes. | 16:59 |
| jmacs | Interesting, thanks. | 16:59 |
| persia | With separated repos, it also becomes easy to flag that a given change is a requirements change without delicate regexes, etc. This can be important if one has a waterfall model (even iterative waterfall with multi-month cycles) and needs to enforce change control in order to ensure schedules are met. | 17:00 |
| persia | But the more I think about this, the more I realise it is just an implementation detail. | 17:01 |
| ChrisPolin | WRT stepping back one layer of abstraction; my approach with these sorts of conceptual introductions is to keep it very abstract in the diagram and offer examples in the explanatory text to compliment. Perhaps the text is a little too implementation-based however. | 17:04 |
| ChrisPolin | It does assert BDD in a 'this is the way it is done' fashion, which I can soften a bit. | 17:06 |
| persia | That's really my concern. There's a lot of environments where the results should be trusted that don't want to work in sprints with ad-hoc requirements development, and a first read of BDD stuff may cause one to think this is mandated. | 17:08 |
| ChrisPolin | Agreed. | 17:08 |
| ChrisPolin | Do you suggest taking all mention of BDD out of the explanation then? Or caveating that it isn't the only game in town? | 17:09 |
| persia | I also suspect there are a fair number of environments where they use XMI or similar to describe some requirements, for which there exist compliance verification systems. I don't see any reason these folk have to change the entire way they think about requirements just to be trustable. | 17:09 |
| persia | I'd suggest avoiding the term "BDD", as I don't know of any results one gets from a BDD search that don't expect some derivative of Agile. | 17:10 |
| ChrisPolin | Cool. | 17:10 |
| persia | Maybe I'm being too careful, but I think it is more useful to use yarn or behave as examples of test framework tooling that can be used, skipping the entire discussion about development methodology. | 17:10 |
| persia | If folk research those, decide they like BDD, and want to go that way (or with a modification thereof), that becomes a safe (and possibly even recommended) path, but I think not mandated. | 17:11 |
| ChrisPolin | A separate 'example implementation' page might be useful here. | 17:12 |
| ChrisPolin | It does raise the same concern slightly though; if those that don't like that approach then associate trustable as a whole with it, they may decided against it. | 17:12 |
| persia | Maybe it doesn't need a separate page. Perhaps, if the system is described as a component diagram, potential software that might implement a given component could be listed at the bottom of that page. | 17:13 |
| ChrisPolin | Sure, that can be done. | 17:13 |
| persia | I really don't think there's any need to mention "BDD" anywhere. BDD is a method for generating software, not a toolset. I very strongly believe that some of the tools used for BDD are tools that should be used for trustable, but that doesn't necessarily imply that the folk using these tools must be doing BDD. | 17:14 |
| persia | To take this to another domain, there are lots of situations in which a roofing hammer is the right tool, even if one isn't working on a roof. | 17:14 |
| ChrisPolin | Haha fair enough. | 17:14 |
| ChrisPolin | Ok, I'll take it out. | 17:15 |
| persia | Mind you, taking it out probably means being a bit more verbose about the important bits, making the use of G/W/T as an example more important. | 17:15 |
| ChrisPolin | I can work around that. | 17:20 |
| ChrisPolin | Happy to move on to the next point? | 17:21 |
| persia | Sure. | 17:24 |
| ChrisPolin | 1) I had left that deliberately vague. I had signed commits in my head, but of course this harks back to the conversation on the mailing list re: sharing passwords etc (how much can you trust that the person on the signature is the person between the screen and the chair?) | 17:24 |
| ChrisPolin | So that's an open question as it stands. | 17:25 |
| persia | OK. As long as it is deliberately vague, I see no issues with it. I just wanted to make sure it was well-understood that this was wishful thinking without careful implementation. | 17:25 |
| persia | (in that most patch tracking systems only loosely enforce this. The more common safe model I see is using ssh keys to authenticate pushes, but that model could also be debated at length) | 17:26 |
| ChrisPolin | It's safer, but again falls at the same hurdle. | 17:27 |
| persia | Yes. | 17:27 |
| ChrisPolin | 2) In a sense, yes it is human review in that the link is in the commit message. What I'm thinking here is ease-of-audit more than machine-enforcible. | 17:29 |
| persia | Some aspects can be handled by machine. For example, any commit that doesn't indicate why it exists could be rejected, etc. | 17:29 |
| ChrisPolin | Yes, true. | 17:30 |
| persia | But I think it is important to indicate that the ultimate responsibility for linking code to requirements belongs to humans, as human activities require a greater level of review/audit than machine activities (because it is that much less possible to prove correct behaviour) | 17:31 |
| ChrisPolin | I can make that clarification, I think you're right. | 17:31 |
| ChrisPolin | 3) They don't have to be a standalone artifact, I was thinking that as they are consumed by a few different components, it would be easier to have them in a dedicated file, but again I'm open to correction here. | 17:34 |
| persia | Most of the patch tracking systems I've used that support CI provide a means to show the CI results (including executed tests) in the patch tracker. One of the results might be generated artifacts. | 17:36 |
| persia | As an example, for one project I watch, one of the build artifacts is a javascript application that loads in a browser. One of the "tests" just generates this application and posts it as a "result" to the patch tracker, so that human reviewers can load the application in their browser easily if they want to check the behaviour of some bit of code. | 17:37 |
| persia | But I'm not sure I understand how any test artifacts would be consumed outside the CI system. Aren't they only relevant for the patch review? | 17:37 |
| ChrisPolin | My thought process might be explained better with my explanation of paragraph 5. | 17:38 |
| persia | Happy to table this point until after that discussion :) | 17:38 |
| ChrisPolin | Which it appears we have reached! | 17:39 |
| persia | Well, unless you want to revisit the notes on paragraph 2 for paragraph 4, but I think that would be redundant :) | 17:39 |
| ChrisPolin | This is again a bit of a 'high-level abstraction vs implementation' debate. | 17:39 |
| ChrisPolin | I'm only aware of one approach to automatically produce the SSP, although I'm sure there are several. | 17:40 |
| persia | To make sure we're talking about the same thing, could you expand "SSP"? | 17:41 |
| ChrisPolin | But the OpenControl project is the one we have researched for this purpose, are you familiar with it? I'll make a note to link our opencontrol page here. | 17:42 |
| ChrisPolin | SSP is the System Security Plan, it's the documentation that you must produce to an auditor which details compliance to a standard. | 17:42 |
| persia | I'm loosely familiar with Open Control. For the purposes of this discussion, would you agree that an "SSP" is a representative of the class of compliance documentation produced by comparing requirements to implementation and generating a report matching some predefined template? | 17:44 |
| ChrisPolin | Yes, although I think it is specific to the standard compliance domain. | 17:45 |
| persia | Maybe? When I worked in the finance industry, projects had to submit compliance reports to the information security office, which didn't have that acronym, were likely in a different format, but I think serve the same purpose. | 17:46 |
| ChrisPolin | I see! Like the man in the orthopaedic shoes, I stand corrected. | 17:47 |
| persia | Note that industry is very wide. There may be vast sectors for which a standardised SSD is normal. | 17:47 |
| persia | Err, SSP. | 17:48 |
| ChrisPolin | I can generalise the mention of SSPs in which case. | 17:48 |
| ChrisPolin | The initial point however, is that the compliance documentation is produced is created using some software (in this case, Compliance Masonry - I'm not aware of others) which consumes a yaml file with a narrative detailing how each control is satisfied. | 17:50 |
| persia | I am reminded of an old standard for electronic document interchange (I recall X.25, but my search engine disagrees with the number). It specified how to format invoices, shipping labels, etc. for electronic transmission between sites. It was used by a vast number of companies, but also entirely alien to other sectors, to the degree that when SOAP became a thing, everyone invented new ways of sharing documents, as if there had been no standard. | 17:50 |
| ChrisPolin | Lol this is a large elephant indeed, in which case. | 17:51 |
| persia | Right. I'm presuming that Compliance Masonry requires a special input format, which could be generated by one of the "tests" in the CI system. | 17:51 |
| ChrisPolin | Precisely. | 17:51 |
| persia | And perhaps again when things merge, so that one has up-to-date compliance information. | 17:52 |
| ChrisPolin | It can also be converted to from a Mustard yaml. | 17:52 |
| persia | (this was "Produce Development Compliance Report" and "Produce SSP" in my draft diagram, with the former representing something that could be in production, and the latter representing what was in production) | 17:52 |
| persia | Converted from a Mustard yaml? That worries me. | 17:53 |
| persia | In my mind, the Mustard documents the requirements, so doesn't change except when the requirements change. As a result of this, it becomes hard for this to reflect when or how a given requirement is implemented. | 17:53 |
| persia | An alternate view is that there exists some requirements repository in some format, and that a Mustard containing the current mapping is produced at the time of each merge to the development branch. | 17:54 |
| persia | But that breaks the assumption of the first paragraph. | 17:54 |
| *** AlisonChaiken has quit IRC | 17:57 | |
| persia | Aha. Found the old EDI format. "ANSI X12" | 18:00 |
| persia | Re-reading the last paragraph, I suppose the source of my confusion is the uncertainty about how the metadata is stored, combined with the subtle distinctions between CI and CD that mean that compliance documentation ends up being generated multiple times: at push time (so reviewers can know if a patch breaks or adds compliance), at merge time (so everyone can check the compliance status of the development branch), and at deploy time (so that the | 18:07 |
| persia | production system compliance is documented properly). | 18:07 |
| ChrisPolin | In the case of compliance masonry, it reads in an 'opencontrol.yaml' file, which is separate from the mustard yaml. jmacs has created a script to convert from one schema to the other, but there is no reason why the conversion can't be influenced by external information from the CD/CI | 18:08 |
| ChrisPolin | 'influenced' is very vague here, but I'm thinking out loud. | 18:08 |
| persia | Ah, yes, that makes sense. A script that consumes the Mustard YAML, is informed by info available from the patch tracking/testing systems (driven by CI/CD), and then produces output that can be consumed to generate compliance information. | 18:08 |
| ChrisPolin | Yes. | 18:09 |
| persia | And now the model makes sense, if not the text of the last paragraph. I'm still not sure how to critique that in detail :) | 18:09 |
| ChrisPolin | I'll link this page in the narrative, but for your information: https://gitlab.com/trustable/overview/wikis/report#mustard | 18:10 |
| persia | and, going back to point 3 of paragraph 3, I think the test artifacts end up getting the same sort of treatment as the compliance artifacts, in the sense that there may be multiple ways to produce them (ideally from the same scripts), called at multiple times during the process, for consumption by multiple entities. | 18:10 |
| ChrisPolin | Yes, I believe so. | 18:10 |
| persia | Well, I hope that critique was useful. Please let me know if you want me to look at it again at that level of detail. | 18:11 |
| ChrisPolin | Absolutely, thank you. I'll revise the text and see how it reads from there. | 18:12 |
| *** AlisonChaiken has joined #trustable | 18:16 | |
| *** tiagogomes has quit IRC | 18:33 | |
| *** laurenceurhegyi has quit IRC | 18:43 | |
| persia | Oh, I thought of another reason to separate requirements and code repos: in a complex deployment situation (e.g. devices), one may end up receiving a requirements update, and want to be able to demonstrate that those requirements are already met without any code changes (to avoid a renewed depoyment). This is eased by being able to demonstrate compliance with top-level VCS metadata, rather than direct diff of the code. Although, again, an | 18:47 |
| persia | implementation detail. | 18:47 |
| *** ctbruce has quit IRC | 19:17 | |
| *** ctbruce has joined #trustable | 19:17 | |
| jmacs | It's very much a prototype at the moment, but could people look at https://gitlab.com/trustable/overview/wikis/pages/plantuml-example and see if that's what they had in mind for PlantUML rendering? | 19:39 |
| jmacs | (No rush, I'm heading home now) | 19:39 |
| persia | That renders as expected for me. Nice work. | 19:49 |
| persia | Frustratingly, when attempting to update the local git repo to see the source, I get "fatal: https://gitlab.com/trustable/overview.wiki/info/refs not valid: is this a git repository?" | 19:51 |
| persia | (for both `git pull` in an existing local repo, and when trying to clone a new repo) | 19:52 |
| jmacs | I think I've seen that error recently but I can't remember where right now | 21:02 |
| *** ctbruce has quit IRC | 23:53 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!