| *** AlisonChaiken has quit IRC | 03:07 | |
| *** AlisonChaiken has joined #trustable | 05:17 | |
| *** ctbruce has joined #trustable | 09:20 | |
| *** ChrisPolin has joined #trustable | 09:22 | |
| *** tiagogomes has joined #trustable | 09:28 | |
| *** laurenceurhegyi has joined #trustable | 09:46 | |
| *** tiagogomes has quit IRC | 11:05 | |
| persia | ChrisPolin: Reading the text, I think some of the specific things I mentioned are covered, but I'm still uncertain about the flow. Maybe it makes sense to look at the diagram rather than the text, and draw the text from that? | 11:13 |
|---|---|---|
| persia | So, in my mind, the diagram contains a couple different types of things. Standards, Requirements, Test Artifacts, Code, etc. seem to me to be types of data. | 11:14 |
| persia | Whereas Continuous Integration, Automerger, etc., seem to be descriptions of systems that perform some action. | 11:14 |
| persia | If that mapping makes sense to you, perhaps it might be sensible to separate out just the systems/functions/actions, and consider inputs and outputs? | 11:15 |
| ChrisPolin | Continue your thought, I don't quite follow the last part. | 11:16 |
| *** tiagogomes has joined #trustable | 11:17 | |
| persia | Heh, let's explore that first then, as the rest of my thoughts rather depend on it. | 11:17 |
| persia | So, if we take "Standards" as an example, I don't see that as a function. "Standards" simply exist. An example function would be "Formalisation", being the process of converting something into a format that is consumable by both humans and computers. | 11:18 |
| ChrisPolin | That makes sense. | 11:18 |
| persia | The "Formalisation" function/action has inputs and outputs. An example input might be a "Standard". An example output might be "Test Procedures". | 11:19 |
| persia | So I was thinking that if we decomposed the diagram, separating the data from the functions, and then considered the input/output of each function, we'd end up with a diagram that made more sense to me. I would hope it might also make more sense to others. | 11:20 |
| ChrisPolin | Ok, I follow now! | 11:20 |
| persia | So, to me, the data items are Standards, Code, SSP, Requirements, Test Artifacts, and Production (where I read "Production Deployment"). Does that match your understanding? We may want more or less as we go through the process, but from the set already on the diagram. | 11:21 |
| ChrisPolin | Yes, that makes sense ok. | 11:23 |
| persia | This leaves "Patch Review", "Continuous Integration", "Complaince (I read "Compliance Masonry"), "Testing", "Automerger", and "Continuous Development" as functions. | 11:24 |
| persia | I suspect this set will also need adjustment, but is probably the most sensible place to start. | 11:25 |
| persia | So, starting from "Patch Review": what are the inputs and outputs? | 11:25 |
| ChrisPolin | In your initial definition, are 'functions' and 'actions' interchangeable? | 11:25 |
| persia | Yes. | 11:25 |
| ChrisPolin | Ok. | 11:25 |
| persia | Well, rather, the distinction isn't important now. | 11:25 |
| persia | Formally, an "Action" is something performed by an "Actor", being either human or automation. | 11:26 |
| persia | An "Activity" is a description of the thing being performed. | 11:26 |
| ChrisPolin | Ok. | 11:26 |
| persia | And the entity (human or automation) engaging in that "Activity" can be said to be performing a "Function". | 11:27 |
| persia | But until we start getting into the system description at a lower level, I'm not sure it matters. | 11:27 |
| ChrisPolin | So, patch review needs an input in the form of a revision of some description, and the standards as a constraint. | 11:27 |
| persia | For now, I'm just loosely batching into "things that do things" and "things that have things done to them", and hoping to think about the relation between those categories, using lay nomenclature. | 11:28 |
| persia | Do we expect the standards to apply pre-integration? My iniital thought was that there were no constraints on submitted patches, but that the CI system would test the integrated revision to determine if constraints were met. | 11:29 |
| persia | (but, yes, broadly, that's the sort of input-to-system that I'm hoping to discuss) | 11:30 |
| ChrisPolin | Yes that makes more sense, I had conflated the role of patch review and CI. | 11:32 |
| persia | I read it as suggesting a revision gate before things landed in the patch tracker, but I think yes, a different system that is often seen. | 11:34 |
| persia | OK, so the patch tracker takes code revisions as an input. | 11:35 |
| persia | I assert that it also takes requirments revisions and standards revisions as input, unless you think those belong somewhere else. | 11:35 |
| ChrisPolin | The standards and requirements inform the CI how to moderate patches from the patch review, so I'd perhaps suggest that they are an input there. | 11:38 |
| persia | Do you anticipate review of revisions to standards and requirements? | 11:40 |
| persia | I agree that, for each patch, the appropriate revision of standards and requirements should control the CI. | 11:41 |
| ChrisPolin | Requirements perhaps, although standards revision is usually out of the hands of the developers. | 11:41 |
| ChrisPolin | But yes, that's a fair point. | 11:41 |
| persia | I was thinking of this as a global system, with varying roles. | 11:41 |
| ChrisPolin | Mm, ok. | 11:42 |
| persia | Taking a devil's advocate position, I suspect that, at least until everyone is following the trustable guidelines, most standards will be formally written in a non-machine-consumable way, so that developers will need to rewrite to implement the standards validation criteria. | 11:42 |
| persia | And I suspect that validation criteria implemented by humans is subject to bugs, and thereby a need for multiple revisions. | 11:43 |
| ChrisPolin | Yes, true. | 11:43 |
| persia | OK, so I think we end up needing more nouns to make this work. | 11:44 |
| persia | Perhaps "Code Revision", "Requirements Revision", and "Standards Revision" as inputs to the patch tracker. | 11:44 |
| persia | And elsewhere something (to be determined later) like "Code", "Requirements", "Standards" that inform the CI? | 11:45 |
| ChrisPolin | Yes, that makes sense. | 11:45 |
| * persia tries to write some UML to avoid too much hand-waving | 11:46 | |
| * persia finds that plantUML renders activity diagrams using different symbols than had previously been studied | 11:47 | |
| ChrisPolin | I'm updating the diagram as I go here. | 11:48 |
| persia | http://www.plantuml.com/plantuml/svg/qz1KK0fABSiipipFKmWkJShDB0OnbHHq5Q834akICnH2YXAJirEBOW40 | 11:49 |
| ChrisPolin | What is the syntax for the data node there? | 11:50 |
| persia | Change "svg" to "uml" in the URL to see the source | 11:50 |
| * persia suddenly wants an etherpad with inline plantUML rendering | 11:51 | |
| ChrisPolin | Got it. | 11:52 |
| persia | Considering Patch Review, I'm thiking the Patch Tracker also has a "voting" input | 11:53 |
| persia | And, presumably, a patch status output. | 11:55 |
| ChrisPolin | Would you consider 'voting' to be a function? | 11:55 |
| persia | Yes. because it's a verb, frustratingly. | 11:56 |
| persia | So, I'm thikning that voting happens by humans and robots at the conclusion of any review. | 11:56 |
| persia | But maybe "voting" is the wrong word. | 11:56 |
| persia | Perhaps "Reviews"? | 11:56 |
| persia | (where a "review" is some data that is input into the patch tracking system) | 11:56 |
| persia | So something like http://www.plantuml.com/plantuml/png/Ymv8B4dEK0WfIapEJYsALKWiLWW8uTBGL50AIYtBBCxCpojMKj2rGnPCBGS9fUINvu750G00 | 11:57 |
| ChrisPolin | Might imply that reviews are a previously existing thing that the patch tracker consumes. It does, but I think the point is more clear when considering it as an action that influences the flow. | 11:58 |
| persia | Right. I'm hoping that details such as "Reviews are created by humans and CI" is something that becomes apparent as we end up with a larger picture. | 11:58 |
| persia | Can you think of any other inputs to the Patch Tracker? | 11:59 |
| ChrisPolin | I think that's comprehensive. Anything else is more the domain of the CI than the patch tracker. | 12:00 |
| persia | True, and we can avoid deciding about CI metadata for now, because we haven't constrained "review", so it can stretch to include as much (or as little) metadata as we want. | 12:01 |
| persia | For patch tracker outputs, the only interface that comes to mind for me is "revision status". | 12:02 |
| ChrisPolin | And the approved patch, of course. | 12:02 |
| persia | I'll also note that I usually call things "candidates" until/unless they have been positively reviewed, where one "candidate" can have multiple "revisions", and the final revision of a candidate is then merged. I'm not sure if this is important at this point. | 12:03 |
| persia | Ah, yes, the patch tracker will need to be able to produce patches. | 12:03 |
| persia | Something like http://www.plantuml.com/plantuml/png/Ymv8B4dEK0WfIapEJYsALKWiLWW8uTBGL50AIYtBBCxCpojMKj2rGnPCBGS9fUINvq740q902a2o4BE2In9BIekLmE9GLI19vyIybCoKn99K1R2or68b0000 ? | 12:04 |
| *** ctbruce has quit IRC | 12:06 | |
| ChrisPolin | By your definition of 'candidate', is this pre-tracker or pre-CI? | 12:06 |
| *** ctbruce has joined #trustable | 12:07 | |
| persia | My definition of "candidate" comes from an age when we didn't use those terms. I used "candidate" to indicate a possible revision that was submitted to a bug tracker in hopes that an authorised developer would review and/or merge it. | 12:09 |
| persia | To me, this maps closely to a patch or patchset that a developer is submitting for review, but I'm not quite sure where it fits on this model, as we're still defining it. | 12:10 |
| persia | For many projects, my "candidate" would be the submission by the developer to the patch tracker. | 12:10 |
| persia | But it is also that artifact, collected from the patch tracker. | 12:10 |
| persia | Which may make it less ideal for this purpose. | 12:10 |
| ChrisPolin | Yes, that's my definition of it too. In which case, are you separating 'Patch tracker' from 'Patch Review'? | 12:10 |
| persia | One of those is a noun, one a verb. | 12:11 |
| persia | To my mind, the source of info for the verb is stored in the noun, and the results of having done the verb are also stored in the noun. | 12:11 |
| persia | But that conflates two different nouns, to some degree. It's perfectly possible to have a system where "patch review" consumes from one system and outputs to another. I'm not sure I have two words for those two things. | 12:12 |
| * persia worries this may have become too abstract | 12:13 | |
| ChrisPolin | I think of them both as nouns, but a patch tracker is a specific piece of software while patch review is the process to which one submits a patch. | 12:14 |
| * ChrisPolin is inclined to agree lol. | 12:14 | |
| persia | Right. I'll try to stay away from that. I think we agree, simply because you describe "patch review" as a "process", and in my semantic mapping, any "process" is inherently a "verb", being something that can be done. | 12:15 |
| * persia ignores the convention of avoiding "do" in certain contexts, like "do swimming" when trying to architect software | 12:16 | |
| ChrisPolin | Ok, I get your meaning. | 12:16 |
| persia | Anyway, I think we agree that there's a component, which we'll call "Patch Tracker", and an activity, which we'll call "Patch Review". | 12:16 |
| ChrisPolin | Cool. | 12:16 |
| persia | But this makes me feel confused about whether we're trying to map components or activities again :( | 12:18 |
| ChrisPolin | I was going to say the same. I think we stick with the data/function approach, and consider components/activities (such as tracker/review) as one function. | 12:19 |
| persia | That raises the question of who/what is performing the action. | 12:20 |
| ChrisPolin | So 'Patch Review' includes components (such as a tracker) and activities (such as the human/machine review of candidates). | 12:20 |
| persia | In my mind, CI does a review of a revision. | 12:20 |
| persia | But if that function belongs in the patch tracker, do we expect CI to be a component of the patch tracker? | 12:20 |
| persia | Note that we can logically assert this without having it constrain our software choices, so we can still use things like Jenkins or Zuul (which are tracker-independent (or at least are working in that direction)) despite claiming CI is a subcomponent. | 12:22 |
| ChrisPolin | Hmm. | 12:22 |
| persia | My thought was something like http://www.plantuml.com/plantuml/png/FOwx3iCW34LtliBAr0xvXIvCR1QWB547Aw0MLO8gcEJt6nxgTdny_LYHU7k3tMdx-Fq9b06jkDrXqlu8EQIOfohryfV-7CeqrHSO9YxTO_UIeWkEs4DB-DwKA8HUO7xKCzh0xD8PUuMsQTDWw1fVPOeSOaabWuhiNplnzLVxLIeXqDIvYoJ2NBw3rM1jVW00 | 12:25 |
| ChrisPolin | Correct me if I'm wrong in my high-level abstraction of this, but I see a patch tracker as something that keeps a record of submitted patches before passing them to the CI for review. Sort of a gatekeeper. The whole process, including Patch Tracker and CI, is Patch Review. | 12:25 |
| ChrisPolin | That's it in a nutshell, yes. | 12:26 |
| persia | I think of a patch tracker as also receiving information back from CI, and being a source for the Automerger (which is where I assign "gatekeeper"), but broadly the same. | 12:26 |
| ChrisPolin | Ok, we're on the same page. | 12:26 |
| persia | Trying to group as you describe: http://www.plantuml.com/plantuml/png/HP0n3uCW48LtViN5oGx-XIQ6oQ49GUDYEX2zMj883K8TclxtWfpjndllktiNoXCK4bzwrTQi1QWLPC-6EdYxe9lHNPDLNnYxERKW54BvyGvf0hS2tWnWo5RdrFWWNdJ9vzPuRO8DApJ6u-oKZoKxm1iMYPAwSQFcbioyiVNAXvo88-7AJ7fI7c5dCCTSf7MoX-gSksKBrMGtSsZH_NLB-anZ8hBXcMGJ5HVmUpOKnBk8entnFpvV | 12:30 |
| ChrisPolin | Perfect. | 12:30 |
| persia | My concern there is that I'm not sure it captures that humans also participate in reviews | 12:31 |
| ChrisPolin | Perhaps include 'voting' in the patch tracker. | 12:31 |
| ChrisPolin | s/in/as an input | 12:32 |
| ChrisPolin | to | 12:32 |
| ChrisPolin | lol | 12:32 |
| persia | When I think of human reviews, I think of votes and comments. | 12:32 |
| persia | And, potentially, artifact attachment. | 12:32 |
| persia | (logs, alternate images, etc.) | 12:32 |
| ChrisPolin | I'd perhaps include all of that in 'Human Review', so as not to convolute the diagram. | 12:33 |
| * persia cheats, assuming we'll figure it out later | 12:33 | |
| persia | Not the best layout (probably because I'm cheating), but http://www.plantuml.com/plantuml/uml/HL2zRi8m4Dxz5ATCTE05CY2GksIeP2KH2s8uaGEY4XlPPp9KVNVi-D9k_lxkEzy-C7gEqqDjFg1gwJM6qTbG0GPeZ-fqYEmcyZVovqmTlfIwUfm8AeDykKDEq5p1Zm8u5QhtUFaMl-aphvtbqKON0pIMwUQHKybYq8rAZhMRPcdkX2mJEqQEHJ6hej4Euu1Ci7YeoDhaSUqHjhlItNQm7TniLspwVzm9tadC96zyPjWaf0tyFHiHqbxYandf7hzArP_qeeTxagzp9jsjBhzP2B6cx9xia4xz1W00 | 12:36 |
| ChrisPolin | Yep, ok. | 12:38 |
| persia | So, we've attached Continuous Integration to Patch Tracker. Are there other inputs/ouputs of Continuous Integration that matter? | 12:38 |
| persia | (some folk like to pre-cache build artifacts, for instance. Others prefer to rebuild post-merge) | 12:39 |
| ChrisPolin | Inputs will also include requirements and standards. | 12:39 |
| persia | Does http://www.plantuml.com/plantuml/png/HL0vRiCm4EpvYeKgfV07L1WGc4Q50O8Kr1Wf26lZ48b9WOTL1FbxUApWZdFip7BxD-WaFaqmpeOET02viEkOedkWlwF_ADHuONtrRIwOwBn1iWh6Fhr-87H2nziNb2JSE_Xb0DT6pLxVlYb7p8NdpaPZaqi19XlnxdNCvTN09vOTFUs4EzKe8bkYYZgcfeX3uTgkPjKHeNfeFovAd5pWT6xTKi5fTRizi9XVM14-7sEYlgT2vx6q7OY_13wHa5Sa7yNba_qnDbwAjPnfUCSd_hWD_L2fXGtjYvMW8Qd-0G00 capture that? | 12:40 |
| persia | Or do you want to break down Code/Requirements/Standards ? | 12:41 |
| ChrisPolin | I think 'Repositories' is too unclear. | 12:41 |
| persia | What do you recommend? | 12:45 |
| ChrisPolin | Hm. Splitting it into the three components will convolute the diagram . | 12:46 |
| persia | http://www.plantuml.com/plantuml/png/HL4zQyCm4DtrAmvFBZH_m4CWg8k7W91Dbj11nDTKj9PSVSH3wN_lIJwJJU_ZtZr9xGiq6XysMkzY0oQ2leZk3H_uxHSC7HoEXRcUSl8pXZk6zs8wdKLBaqCoRZ9XYg-WyIVRW3EwH8Xea7v2eXSVRVB18iSh8Kxd6akdZs1cX4QPTFk4qWFN1du5m7MZnc1kNxnJZOMNtYNhiiyHUfVm7aoYwjKWUq6Ebc-4AoyScDmIgNBAcw9sHL9TEvc4K3tSLAeIfo-bQzsj1pXCVdKxLkCJ3uoF-vYgvxxGD9QN7Scd87iMg2BxE8wUzqy8qMttgD_0YXx-0G00 is very wordy, but contains the words. | 12:47 |
| ChrisPolin | I think that's better. Perhaps lose 'repositories', it's implied that they're kept there. | 12:48 |
| persia | I have a different idea | 12:51 |
| ChrisPolin | Shoot. | 12:51 |
| persia | It was an expansion of http://www.plantuml.com/plantuml/png/HL4nZeGm3Epz2ekAA_O3Mwo4SWq5KWHe6tH51DxTw8u49M4fJlVtIu8HNJoU6O-TyWEBbjxQQsjyWSfZUuVh9xtfnoxahdYv9MIerc1dSazoNubKDL1cvMAz3jPfOh44g9eiYg-7KpDX8LKONvYcq5RWBo0EEzGxDNwpe-mJBgm9sgnszLYRG4-dGWoM2QA6o2WvBsqyi6DmT-o22klUaKT7A3FfIGN2pE6aGYQxzfwovjbjXvV9RkQePN_M7TUtGoRpkqvmbAtBKOcp8Mfkn8ZCOxjul3y061erlhIXT0RZ7zRDvx9Dd-uRjp6JSfDFfX62fZyy9LptC-G_OkEs-mS0 , but I realise that this breaks the "standards | 12:54 |
| persia | implementation should be reviewed" bit. | 12:54 |
| persia | My worry with http://www.plantuml.com/plantuml/png/HL2xRiCm3Dpr5OGd5qX-m4C0Grqy110a8qkGGOZOL6Wj9Nh4Gz1_hrv6DlBkU3oo_u2EurDxROtlG7hW9p9yuXD_xHtT0Fj3HivZ37P1TqDtoQBnIFeqAO8qIZhbTq2jmXrmV4JjS44JcXiZP3mMbrHzERaWT4o6wpVajRXsy280vmhDJbv_sWesPvnQ4xI9DdgOJC2Rao4bBG8waQJesm6ujeMYWTKn9GonCcnZQ0gjbGm8HOELfYpRyLFEMdPp0NjbLxFrR7xtelM7ROoLUifm6elthQDlWawDI16RhjcbR_uHCjGpojCRmSK_ is that it may cause the same interpretation | 12:55 |
| persia | (as a side note, I think we're moving well into "painting" from formal UML, but I beleive this can be fixed in a further revision) | 12:57 |
| ChrisPolin | I don't follow 'Machine Transformation'. | 12:58 |
| ChrisPolin | Ah sorry, I do. | 12:58 |
| persia | That was perhaps badly named. I was thiking the process of changing human-only standards to human+machine standards. | 12:58 |
| persia | But I realise that properly belongs inside the developer in this diagram. | 12:58 |
| ChrisPolin | I agree, it's perhaps superfluous in this diagram at least. | 12:59 |
| persia | What do you think of http://www.plantuml.com/plantuml/png/JL4xRiCm3Drr2i9J2ZGzG8O0WRfu223OHfQWWs0piPfQSYaf6OhUlPGi8_LalW_vI6rUe6hmRhnnrbUWFJGdiNl7Etwv6Ma7str2peSOt8HqHVf8eiDHRB9pTju4HmQBMGdh0WAPwnZ0NH80_7KZUaR_oQ5tDcXZ8Om8VIH26o1F65XN0cKlTqcQDcWxQ1hyApJu7GtXn1Qk60Rf1eIBewoSoNrY7zu4CfFY274uvaMK41VI4qAbTEX7I9lZeu8V7dHUe8vqVojRgYxXaeCQ6rtqKDk0LzA1isM1h0KhDkM6-2X7Q0kuTEJW8IwCMXd9eSsW- | 13:01 |
| persia | L9PKwudLMhNd5BMFBjfOJkuXrrhrJthjjJxrQRoVvrWjiLvhUIJa7KXE6BHbNRyeBz2x9OryhiNecd_0000 ? | 13:01 |
| ChrisPolin | Much clearer. | 13:02 |
| persia | And http://www.plantuml.com/plantuml/png/LLB1ReCm3BtdAwoUEgdT1_HGgM8N3fKYGBrKEsJWqcoGC2UKmxH_dnD2st59_Fnil-UmVe5LWJVjj3Lk1Sf1SHAxDxnXPmUa7Mpt0J7M8tnOxsqFzW9F107yLLU4EmIJxZf0Kzi6eVJAD8eQ1tn2WT-Z9kpHU1TcJTXriK6ua_RQjA3xeOiCvLaJX2wl0hauQ13dmyWQa5gazr1rE8frj31OfxqbZSc5d3MJRgy- | 13:02 |
| persia | I6OWANMCFj5v0i_I1ZoRg4SY7WrnGiEyj9bOorq2vsvfyy_F9ZhCWkcBfSWSo7vYxP_aYyCnRbGASI7L8woaylKLmXFWj88V7dIUeOfK_PLSoYhW6GlLPhIZWznuR2bkA1AoN31ZdHuJfxI4Ce5pHnRknpaZbqp6edMZU5EHaxQNoT2kE0MjSNPHmhQnarbYMJtYCiNxfKp6UnvWBXk79SeUYInF2PQOUAaTF-Yl4BlPHlm1Kw8e_m00 | 13:02 |
| persia | The problem with plantUML URLs is that they keep getting longer and longer :) | 13:02 |
| ChrisPolin | Haha they do indeed, they're already breaking my buffer! | 13:03 |
| ChrisPolin | That's better. The diagram is clean and the notes clear up any ambiguity. | 13:04 |
| persia | So, what is next? | 13:04 |
| persia | (and, do you want to drive the UML for a bit?) | 13:04 |
| persia | Unless you have a different suggestion, I think we're ready for CD. | 13:06 |
| ChrisPolin | Have we included testing here? Or does that fall under CI? I was under the impression that CI tests are fairly lightweight. | 13:07 |
| persia | My apologies: I conflate "CI" with "pre-merge CI", and assign the "post-merge CI" stuff to an automerger. This may be confusing, and may have influenced the UML I wrote. | 13:09 |
| ChrisPolin | Ah ok, that makes sense. | 13:09 |
| persia | For testing, I think there are several classes of test, being A) The tests that one wants to run to confirm something may be merged (usually lightweight), B) The tests that one wants to run to confirm a performed merge is safe (heavier if the pre-merge stuff was light, for safety. Lighter, if the pre-merge stuff was heavy, for speed), and C) tests considered too expensive to be done speculatively (either because they take a long time (slow | 13:11 |
| persia | developer cycle), or because they involve other scarcities (so one only wants to run them occasionally). | 13:11 |
| persia | So, perhaps there is a "Testing" interface that is used by Continuous Integration and Automerger (and potentially more in the future), and drives a Test Environment component. | 13:12 |
| persia | Do you want to draw that, or shall I? | 13:12 |
| * persia imagines the testing interface as being bidirectional | 13:14 | |
| ChrisPolin | I'm still in BDD mode currently, but my idea of 'trustable' involves tests that determine that requirements are met. I guess that falls under all three classes to an extent. | 13:14 |
| ChrisPolin | I can have a go at drawing it. | 13:15 |
| persia | My source is at http://www.plantuml.com/plantuml/uml/LLB1ReCm3BtdAwoUEgdT1_HGgM8N3fKYGBrKEsJWqcoGC2UKmxH_dnD2st59_Fnil-UmVe5LWJVjj3Lk1Sf1SHAxDxnXPmUa7Mpt0J7M8tnOxsqFzW9F107yLLU4EmIJxZf0Kzi6eVJAD8eQ1tn2WT-Z9kpHU1TcJTXriK6ua_RQjA3xeOiCvLaJX2wl0hauQ13dmyWQa5gazr1rE8frj31OfxqbZSc5d3MJRgy- | 13:16 |
| persia | I6OWANMCFj5v0i_I1ZoRg4SY7WrnGiEyj9bOorq2vsvfyy_F9ZhCWkcBfSWSo7vYxP_aYyCnRbGASI7L8woaylKLmXFWj88V7dIUeOfK_PLSoYhW6GlLPhIZWznuR2bkA1AoN31ZdHuJfxI4Ce5pHnRknpaZbqp6edMZU5EHaxQNoT2kE0MjSNPHmhQnarbYMJtYCiNxfKp6UnvWBXk79SeUYInF2PQOUAaTF-Yl4BlPHlm1Kw8e_m00 | 13:16 |
| *** tiagogomes has quit IRC | 14:27 | |
| ChrisPolin | After a fair bit of wrangling with PlantUML (and a break for lunch!), this is the best layout I can get it to come up with. | 14:34 |
| ChrisPolin | http://www.plantuml.com/plantuml/png/LL91Ri8m4Bpx5QkSg0Hz00Sab7BWW1Gb4HVKGveiu3QnKziXXwf_x-x60OeYOOzdTsV6Nhn0akDDUssDJw3oa1_L-WrlsDeUtHfM6qQC3GWVDWJRWJt34q41_SehmXs2KRSjeAbjWr24oZILQppGF-JuFMY77PhWUTQ8RIiDUErqqEO2kkjROLI1D05tULL8nQn1dRO3QK1tGVVELTk3EfNe0-pCJJjhk50EofrQYBVUUXsiqnZjPO9p3KqJg2pKPD3fopMmFo95MvxGfnOaXuHf0u4SruDpD0v4JaEy6AFKKXVctFql_vbVIXmf9tIsJfYzivzOXoUlQdk0LMD7mtUGANLsLOUGP5Mehy2NXcC2FpJjD46bg-glc | 14:34 |
| ChrisPolin | 4jMCfwIMcq6EtZOcu0N9vaA8TqhOj2tY2y0nnXG4S6fAHa8mtIIpISfYTTDHOa99oQRPjmnF_AJaV5vSPSl-wnyx8kutynbcQpt35FPqC-xz76GxkC1IOmykJ52w1dyCiQ9RVX29tPSbeKiTsez6PLtFGTR_040 | 14:34 |
| persia | That works for me. I could hope for a better layout engine though :) | 14:35 |
| persia | Actually, I think the arrows to Testing are all bidirectional | 14:36 |
| persia | But aside from that. | 14:36 |
| persia | So, on to Continuous Deployment? | 14:37 |
| ChrisPolin | http://www.plantuml.com/plantuml/png/LL9DRy8m3BtdLrYScCJs0z24X3eEFI1LRSG5xT2r1hALf4jIUfZstsUxuMEe4l7Bi_sUu_aJp4gyc62S3JEe0vGxjNp32tQkHx-4vnKZraM43nUZEuCxm0D10Vtq2U46mMYw3j0shaMeOctRshS1w1zA_1wCnpFQ6BZNY5qd1VZiJJJs2ERSTyAe8sa2hlAYa99PWzgl1zA0_eZ-dRFMMxNN629ixCLuPpbHBlH6pSLRxuA9pXjCzWh1EOUw2QGhDHdqvdYAx8z8oLOWzA44oI5Xna8anytWFRK3aTCIBurHSgaASsx-5__CBsGS6K_euBmmU-y-iOaFNjLw2y-j6os_GQ7KmTTdX5bHn-O4_6Wupk27kkqdIFkw- | 14:37 |
| ChrisPolin | KfpAJJZ6QarTd13WDn6F7gPgH2oN163lddQ01pJWAe4JaN9G1occ-9wav5uqzOqCU6aoMO5Lontl3BIlgnkyYKkz3skKhowfXLopXccjA6_Hjdz8ilJ1KbCF7anGcWDVXcZYRrIgAk9VZlhYglGJYmdgxBPrz5MVm00 | 14:37 |
| ChrisPolin | Ok, lets move on. | 14:37 |
| persia | Right. From that last revision, I'd change "TS -> TE" to "TS <-> TE", but otherwise looks perfect. | 14:38 |
| persia | So, I see Continuous Deployment as a component that consumes the Repositories interface. Does that seem sensible to you? | 14:39 |
| *** tiagogomes has joined #trustable | 14:39 | |
| ChrisPolin | Yes, with all of the previous operations being carried out to keep repositories up to date. | 14:40 |
| ChrisPolin | Ok. | 14:41 |
| persia | That's my thought. | 14:41 |
| persia | And I am imaginging two outputs of the CD system. | 14:41 |
| persia | One is a Compliance Document, and the other is a Production Deployment | 14:42 |
| persia | But I'm not sure how to position the expensive testing facility. Perhaps CD also uses the Testing interface bidirectionally? | 14:42 |
| persia | (layout note: it may make sense to put the repositories note on the left of the interface) | 14:43 |
| ChrisPolin | I would say so. It needs to be made clear also that the 'Repositories' also contains the separate compliance data to be consumed by Compliance Masonry. | 14:44 |
| ChrisPolin | Although perhaps this is in the test. | 14:44 |
| ChrisPolin | text* | 14:44 |
| persia | What sort of separate compliance data do you imagine? Why wouldn't that go through the same process as everything else? | 14:44 |
| ChrisPolin | Sorry, I'm thinking implementation again. The separate compliance yaml that consumes requirements, patch commit messages and test results. | 14:46 |
| ChrisPolin | But this falls under the umbrella of CD. | 14:46 |
| ChrisPolin | Broadly speaking. | 14:46 |
| persia | Was that something that was autogenerated from template, or something created by a human? | 14:47 |
| ChrisPolin | Currently it's generated from a mustard yaml using a script that jmacs wrote, but it doesn't have all the functionality that I'm describing yet. So it would be primarily autogenerated, in theory. | 14:48 |
| persia | Actually, that question doesn't matter. | 14:48 |
| persia | I'm thinking that either A) it is done manually or B) it is done automatically | 14:48 |
| persia | In case (A), it should be reviewed, so goes through everything above. | 14:48 |
| persia | In case (B) the code to generate it should be reviewed, so goes through everything above. | 14:48 |
| persia | That said, it makes sense to be clear in the note that "code" means not only the core implenentation, but also any of the automation that causes the system to behave as it does. | 14:49 |
| persia | Well, and really, any other artifacts that end up being submitted to the system. | 14:49 |
| ChrisPolin | Yes, that makes sense. | 14:50 |
| persia | Heh, which means that even though I questioned it, I am actually agreeing with you that we need the note to indicate a broader set of potential contents for the repository. | 14:51 |
| persia | And, in practice, I think we aren't specifying the format of the compliance document. There might be another system (e.g. Compliance Masonry) that consumes the "Compliance Document" interface of the CD system, and produces something more human consumable. | 14:52 |
| ChrisPolin | Yes, that's the case. | 14:53 |
| persia | RIght. In that case, I think we've reached agreement again :) | 14:53 |
| *** sambishop has quit IRC | 14:58 | |
| ChrisPolin | http://www.plantuml.com/plantuml/png/LLF1YkCm3BtxAqHFNPYP3oZBG4bxw64WD64kPG-UH6azuzXPssaeo_xxIegRwPP2BUb9UdfIrpzWTSIhYSQxk08TuVYkDZkyelK3XWqylxB7-OJmuLFoFVWE7W0Aw5DV41ONJCPQGDVu5g5AshKwj17e5uxuUpG1UtGfSgy9hPK2_0uc6NS6qmzM43eH9-0gBmefcJceqtOa3XZE67vnrlPDdMgC2VRkQe9td2Y1Ug_MCjlWeqa-6CpZbUBd7EechhfIyu0MkyJZ4IPF5H72GmLYGxoCWqG3DsC8r0s4JKkuhABaKXN6BEC__JVxawXHi42T3u8SWl_49hr8zi61Rbl30Z3q1fuW0NH8fjCDQHV7ZzwaH6sJb_HuY | 14:59 |
| ChrisPolin | mbxIUQAn3EE_I0AjcDWNHar-V3LMJ_DAz8sUg8T3T6Wyeyog-qRFBT-Shp-Kgakw1vXLUhKN83l1QSL_A5sfzbL1zryvPMKDViBKiguqO-Hfabu3h9E0HG7HGZwhlFnuPHtKsNdN9J4I-CSAU-HWeGphQPb2IOljIYvul6ThrNQ7wk5ljXb_MrNsNwzfvNoFh2RqiRXRXNVWUAG0qGnuu8vNn9vw0B_ieyK-qbcNStmvLrNytklDlEiyg-wQolb7iNQuM3zRJdZOgSK4ypuOlSF | 14:59 |
| ChrisPolin | That should hopefully encompass those other automation components and data. | 15:00 |
| * persia tries to add a bit more, hoping the layout won't break | 15:00 | |
| *** sambishop has joined #trustable | 15:01 | |
| persia | Every attempt to link CD to Testing is ugly, but http://www.plantuml.com/plantuml/png/LLDDY-Cm3BtxLuYUkZ0pFw0i0oNfeOT2QC9SoXuyYTfw9h6p_cWeo_xtbHJtOqkWblmaFJt9on-msEF51EDiM80EiFzGgn8lsBiH_GfUtzbZNKJuT36w0TmHdW0AwDUS4Uukc4pV0zhMTGXrrBRJlWj0_x37tybu7D36mBKcx7j9m6Tleh4dCCFO2q97uWISvKqX1JC7TLWdue3-XFuNHwrtwj1WYB2n5-ETvK2vQ3PgARsDBfZelC7SNYL- | 15:03 |
| persia | Zg5gucfgDJVOup5oUuJ9NGK4_vI1s10lOo5Imstodgg1iEa8brMKMCh2c7lxB__r_Y9g52pGqNb1ZjvzOHlV97fhGNUTOG4OUWL740_QHtFKBMaNqkTWOgIoqKbuk8Q8WmHpHk8PqZ2AWbtoh2kZ9kU_ZxsRvX7fFZYY7GpHeFJFCglr3buxDraUVwNKqUi1OL7fs9w1zmMd1VoXSeVPrNZTVkUHL0tx2rBAsEHIe6uYdhoCKm35LX62lcLUFfpoREhid9EIU37DDzNjfY3XJATfM8B9GoqgphZ_u6sLyllwJb_igddOTRRVRs6LdBVifh0qtgpYSL5iymLHp3XlJkT87jh0l- | 15:03 |
| persia | mZnNwIsTGp_7vkwlcyKMerDolFwYOkvNlMgiInTzVx5XUbKimlezcKzQsywr8hutr4p4gL0YWSFIEZRKiFqxL9jcwMQgTKKOfGPJuKkty0 | 15:03 |
| persia | Does that look right to you? | 15:03 |
| ChrisPolin | That looks good! =) | 15:05 |
| ChrisPolin | I think it has all the constituent parts we need. | 15:06 |
| persia | Cool. This probably imapacts the text as well, but it might take a bit to get that in a reviewable shape. | 15:07 |
| ChrisPolin | Certainly. | 15:07 |
| ChrisPolin | But it's in shape to work with now. | 15:07 |
| laurenceurhegyi | That link isn't working for me, persia. I am missing something? | 15:08 |
| ChrisPolin | You may have to paste all the parts of it into your browser laurenceurhegyi. | 15:08 |
| persia | laurenceurhegyi: It's long enough that it might have split over several lines on your IRC client. | 15:08 |
| ChrisPolin | It splits over the buffer on my chat cleint. | 15:08 |
| persia | Mine as well, at this point | 15:08 |
| laurenceurhegyi | ah, that's better. I had pasted them all in separately but not correctly | 15:10 |
| *** tiagogomes has quit IRC | 15:12 | |
| *** ChrisPolin has quit IRC | 15:18 | |
| *** sambishop has quit IRC | 15:26 | |
| *** sambishop has joined #trustable | 16:42 | |
| *** AlisonChaiken has quit IRC | 16:45 | |
| *** AlisonChaiken has joined #trustable | 17:05 | |
| *** sambishop has quit IRC | 18:02 | |
| *** laurenceurhegyi has quit IRC | 18:24 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!