IRC logs for #trustable for Friday, 2016-12-23

*** AlisonChaiken has quit IRC03:07
*** AlisonChaiken has joined #trustable05:17
*** ctbruce has joined #trustable09:20
*** ChrisPolin has joined #trustable09:22
*** tiagogomes has joined #trustable09:28
*** laurenceurhegyi has joined #trustable09:46
*** tiagogomes has quit IRC11:05
persiaChrisPolin: 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
persiaSo, 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
persiaWhereas Continuous Integration, Automerger, etc., seem to be descriptions of systems that perform some action.11:14
persiaIf 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
ChrisPolinContinue your thought, I don't quite follow the last part.11:16
*** tiagogomes has joined #trustable11:17
persiaHeh, let's explore that first then, as the rest of my thoughts rather depend on it.11:17
persiaSo, 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
ChrisPolinThat makes sense.11:18
persiaThe "Formalisation" function/action has inputs and outputs.  An example input might be a "Standard".  An example output might be "Test Procedures".11:19
persiaSo 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
ChrisPolinOk, I follow now!11:20
persiaSo, 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
ChrisPolinYes, that makes sense ok.11:23
persiaThis leaves "Patch Review", "Continuous Integration", "Complaince (I read "Compliance Masonry"), "Testing", "Automerger", and "Continuous Development"  as functions.11:24
persiaI suspect this set will also need adjustment, but is probably the most sensible place to start.11:25
persiaSo, starting from "Patch Review": what are the inputs and outputs?11:25
ChrisPolinIn your initial definition, are 'functions' and 'actions' interchangeable?11:25
persiaWell, rather, the distinction isn't important now.11:25
persiaFormally, an "Action" is something performed by an "Actor", being either human or automation.11:26
persiaAn "Activity" is a description of the thing being performed.11:26
persiaAnd the entity (human or automation) engaging in that "Activity" can be said to be performing a "Function".11:27
persiaBut until we start getting into the system description at a lower level, I'm not sure it matters.11:27
ChrisPolinSo, patch review needs an input in the form of a revision of some description, and the standards as a constraint.11:27
persiaFor 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
persiaDo 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
ChrisPolinYes that makes more sense, I had conflated the role of patch review and CI.11:32
persiaI 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
persiaOK, so the patch tracker takes code revisions as an input.11:35
persiaI assert that it also takes requirments revisions and standards revisions as input, unless you think those belong somewhere else.11:35
ChrisPolinThe 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
persiaDo you anticipate review of revisions to standards and requirements?11:40
persiaI agree that, for each patch, the appropriate revision of standards and requirements should control the CI.11:41
ChrisPolinRequirements perhaps, although standards revision is usually out of the hands of the developers.11:41
ChrisPolinBut yes, that's a fair point.11:41
persiaI was thinking of this as a global system, with varying roles.11:41
ChrisPolinMm, ok.11:42
persiaTaking 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
persiaAnd I suspect that validation criteria implemented by humans is subject to bugs, and thereby a need for multiple revisions.11:43
ChrisPolinYes, true.11:43
persiaOK, so I think we end up needing more nouns to make this work.11:44
persiaPerhaps "Code Revision", "Requirements Revision", and "Standards Revision" as inputs to the patch tracker.11:44
persiaAnd elsewhere something (to be determined later) like "Code", "Requirements", "Standards" that inform the CI?11:45
ChrisPolinYes, that makes sense.11:45
* persia tries to write some UML to avoid too much hand-waving11:46
* persia finds that plantUML renders activity diagrams using different symbols than had previously been studied11:47
ChrisPolinI'm updating the diagram as I go here.11:48
ChrisPolinWhat is the syntax for the data node there?11:50
persiaChange "svg" to "uml" in the URL to see the source11:50
* persia suddenly wants an etherpad with inline plantUML rendering11:51
ChrisPolinGot it.11:52
persiaConsidering Patch Review, I'm thiking the Patch Tracker also has a "voting" input11:53
persiaAnd, presumably, a patch status output.11:55
ChrisPolinWould you consider 'voting' to be a function?11:55
persiaYes. because it's a verb, frustratingly.11:56
persiaSo, I'm thikning that voting happens by humans and robots at the conclusion of any review.11:56
persiaBut maybe "voting" is the wrong word.11:56
persiaPerhaps "Reviews"?11:56
persia(where a "review" is some data that is input into the patch tracking system)11:56
persiaSo something like
ChrisPolinMight 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
persiaRight.  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
persiaCan you think of any other inputs to the Patch Tracker?11:59
ChrisPolinI think that's comprehensive. Anything else is more the domain of the CI than the patch tracker.12:00
persiaTrue, 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
persiaFor patch tracker outputs, the only interface that comes to mind for me is "revision status".12:02
ChrisPolinAnd the approved patch, of course.12:02
persiaI'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
persiaAh, yes, the patch tracker will need to be able to produce patches.12:03
persiaSomething like ?12:04
*** ctbruce has quit IRC12:06
ChrisPolinBy your definition of 'candidate', is this pre-tracker or pre-CI?12:06
*** ctbruce has joined #trustable12:07
persiaMy 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
persiaTo 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
persiaFor many projects, my "candidate" would be the submission by the developer to the patch tracker.12:10
persiaBut it is also that artifact, collected from the patch tracker.12:10
persiaWhich may make it less ideal for this purpose.12:10
ChrisPolinYes, that's my definition of it too. In which case, are you separating 'Patch tracker' from 'Patch Review'?12:10
persiaOne of those is a noun, one a verb.12:11
persiaTo 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
persiaBut 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 abstract12:13
ChrisPolinI 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
persiaRight.  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 software12:16
ChrisPolinOk, I get your meaning.12:16
persiaAnyway, 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
persiaBut this makes me feel confused about whether we're trying to map components or activities again :(12:18
ChrisPolinI 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
persiaThat raises the question of who/what is performing the action.12:20
ChrisPolinSo 'Patch Review' includes components (such as a tracker) and activities (such as the human/machine review of candidates).12:20
persiaIn my mind, CI does a review of a revision.12:20
persiaBut if that function belongs in the patch tracker, do we expect CI to be a component of the patch tracker?12:20
persiaNote 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
persiaMy thought was something like
ChrisPolinCorrect 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
ChrisPolinThat's it in a nutshell, yes.12:26
persiaI 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
ChrisPolinOk, we're on the same page.12:26
persiaTrying to group as you describe:
persiaMy concern there is that I'm not sure it captures that humans also participate in reviews12:31
ChrisPolinPerhaps include 'voting' in the patch tracker.12:31
ChrisPolins/in/as an input12:32
persiaWhen I think of human reviews, I think of votes and comments.12:32
persiaAnd, potentially, artifact attachment.12:32
persia(logs, alternate images, etc.)12:32
ChrisPolinI'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 later12:33
persiaNot the best layout (probably because I'm cheating), but
ChrisPolinYep, ok.12:38
persiaSo, 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
ChrisPolinInputs will also include requirements and standards.12:39
persiaDoes capture that?12:40
persiaOr do you want to break down Code/Requirements/Standards ?12:41
ChrisPolinI think 'Repositories' is too unclear.12:41
persiaWhat do you recommend?12:45
ChrisPolinHm. Splitting it into the three components will convolute the diagram .12:46
persia is very wordy, but contains the words.12:47
ChrisPolinI think that's better. Perhaps lose 'repositories', it's implied that they're kept there.12:48
persiaI have a different idea12:51
persiaIt was an expansion of , but I realise that this breaks the "standards12:54
persiaimplementation should be reviewed" bit.12:54
persiaMy worry with is that it may cause the same interpretation12: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
ChrisPolinI don't follow 'Machine Transformation'.12:58
ChrisPolinAh sorry, I do.12:58
persiaThat was perhaps badly named.  I was thiking the process of changing human-only standards to human+machine standards.12:58
persiaBut I realise that properly belongs inside the developer in this diagram.12:58
ChrisPolinI agree, it's perhaps superfluous in this diagram at least.12:59
persiaWhat do you think of
persiaL9PKwudLMhNd5BMFBjfOJkuXrrhrJthjjJxrQRoVvrWjiLvhUIJa7KXE6BHbNRyeBz2x9OryhiNecd_0000 ?13:01
ChrisPolinMuch clearer.13:02
persiaThe problem with plantUML URLs is that they keep getting longer and longer :)13:02
ChrisPolinHaha they do indeed, they're already breaking my buffer!13:03
ChrisPolinThat's better. The diagram is clean and the notes clear up any ambiguity.13:04
persiaSo, what is next?13:04
persia(and, do you want to drive the UML for a bit?)13:04
persiaUnless you have a different suggestion, I think we're ready for CD.13:06
ChrisPolinHave we included testing here? Or does that fall under CI? I was under the impression that CI tests are fairly lightweight.13:07
persiaMy 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
ChrisPolinAh ok, that makes sense.13:09
persiaFor 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 (slow13:11
persiadeveloper cycle), or because they involve other scarcities (so one only wants to run them occasionally).13:11
persiaSo, 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
persiaDo you want to draw that, or shall I?13:12
* persia imagines the testing interface as being bidirectional13:14
ChrisPolinI'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
ChrisPolinI can have a go at drawing it.13:15
persiaMy source is at
*** tiagogomes has quit IRC14:27
ChrisPolinAfter 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
persiaThat works for me.  I could hope for a better layout engine though :)14:35
persiaActually, I think the arrows to Testing are all bidirectional14:36
persiaBut aside from that.14:36
persiaSo, on to Continuous Deployment?14:37
ChrisPolinOk, lets move on.14:37
persiaRight.  From that last revision, I'd change "TS -> TE" to "TS <-> TE", but otherwise looks perfect.14:38
persiaSo, I see Continuous Deployment as a component that consumes the Repositories interface.  Does that seem sensible to you?14:39
*** tiagogomes has joined #trustable14:39
ChrisPolinYes, with all of the previous operations being carried out to keep repositories up to date.14:40
persiaThat's my thought.14:41
persiaAnd I am imaginging two outputs of the CD system.14:41
persiaOne is a Compliance Document, and the other is a Production Deployment14:42
persiaBut 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
ChrisPolinI 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
ChrisPolinAlthough perhaps this is in the test.14:44
persiaWhat sort of separate compliance data do you imagine?  Why wouldn't that go through the same process as everything else?14:44
ChrisPolinSorry, I'm thinking implementation again. The separate compliance yaml that consumes requirements, patch commit messages and test results.14:46
ChrisPolinBut this falls under the umbrella of CD.14:46
ChrisPolinBroadly speaking.14:46
persiaWas that something that was autogenerated from template, or something created by a human?14:47
ChrisPolinCurrently 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
persiaActually, that question doesn't matter.14:48
persiaI'm thinking that either A) it is done manually or B) it is done automatically14:48
persiaIn case (A), it should be reviewed, so goes through everything above.14:48
persiaIn case (B) the code to generate it should be reviewed, so goes through everything above.14:48
persiaThat 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
persiaWell, and really, any other artifacts that end up being submitted to the system.14:49
ChrisPolinYes, that makes sense.14:50
persiaHeh, 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
persiaAnd, 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
ChrisPolinYes, that's the case.14:53
persiaRIght.  In that case, I think we've reached agreement again :)14:53
*** sambishop has quit IRC14:58
ChrisPolinThat should hopefully encompass those other automation components and data.15:00
* persia tries to add a bit more, hoping the layout won't break15:00
*** sambishop has joined #trustable15:01
persiaEvery attempt to link CD to Testing is ugly, but
persiaDoes that look right to you?15:03
ChrisPolinThat looks good! =)15:05
ChrisPolinI think it has all the constituent parts we need.15:06
persiaCool.  This probably imapacts the text as well, but it might take a bit to get that in a reviewable shape.15:07
ChrisPolinBut it's in shape to work with now.15:07
laurenceurhegyiThat link isn't working for me, persia. I am missing something?15:08
ChrisPolinYou may have to paste all the parts of it into your browser laurenceurhegyi.15:08
persialaurenceurhegyi: It's long enough that it might have split over several lines on your IRC client.15:08
ChrisPolinIt splits over the buffer on my chat cleint.15:08
persiaMine as well, at this point15:08
laurenceurhegyiah, that's better. I had pasted them all in separately but not correctly15:10
*** tiagogomes has quit IRC15:12
*** ChrisPolin has quit IRC15:18
*** sambishop has quit IRC15:26
*** sambishop has joined #trustable16:42
*** AlisonChaiken has quit IRC16:45
*** AlisonChaiken has joined #trustable17:05
*** sambishop has quit IRC18:02
*** laurenceurhegyi has quit IRC18:24

Generated by 2.14.0 by Marius Gedminas - find it at!