IRC logs for #trustable for Friday, 2019-03-15

*** toscalix has joined #trustable08:45
*** toscalix has quit IRC08:46
*** toscalix_ has joined #trustable08:47
reiterativepersia: Are you saying that we should restrict 'Trustable' evidence to that which can be transmitted via a t.history? Because we've already identified a number of things (t.opinion, t.proposal) that MAY sit outside a t.history.10:06
persiaI am saying that,.10:06
persiaI also don't understand how t.proposal sits outside t.history.10:06
reiterativeIt may be a patchset on a mailing list10:07
persiaEither t.proposal sits atop a speculative history or t.proposal forms a new history, at the time of creation.10:07
persiaA patchset on a mailing list sits atop a speculative history.10:07
persiaSimilarly, t.opinion is about a patchset, so associated with that patchset in history.10:08
persiaThere are N impliementations, of course.  If t.proposal is a git commit on a branch, and t.opinion is encoded in NoteDB, it's all in git, so a carefully crafted `git fetch` gets you everything.10:08
persiaIf both are posts to a mailing list, then the t.history is the combination of the mailing list and e.g. a downloadable directory of tarballs, to one of which the patchset applies.10:10
persiaBut those are implementation details.10:10
reiterativeYes, but if we want to assert that a t.history MUST allow transmission of the evidence relating to t.opinions and t.proposals, then we need to make that clear in our definition10:11
reiterativeI don't think it is at present10:11
reiterativeIt also has clear implications for the integrity of the t.histoiry if some implementations of t.history may involve the coordination of several discrete elements10:12
persiaAs a matter of record, a "git repository" is organised as a set of discrete elements :)10:33
persiaThat said, I don't know why it matters.  A t.history is the (possibly collective) set of things that is CONSUMEd.10:34
persiaI agree that implementations that use math to demonstrate relations between elements are likely to have greater integrity than impementations that involve a single human orally recounting the results.10:35
persiaFrom git, "t.history: a recorded sequence of evaluated t.proposals".  I'm not sure how this implies any coherency to the sequence.10:38
persiaFrom that definition, I think it would be reasonable to implement a history as a list messageIDs for mailing list posts, and have some confidence that this provided sufficient specificity to be a unique and reliable t.history.10:38
persiaImplementing as a list of messageID+SHA256 of message probably even provides a fair degree of protection from tampering.10:39
persiaOh, and I don't think there is any sort of MUST about opinions.10:43
persiaIf a given t.history doesn't include sufficient reference to understand the opinions, then the opinions simply cannot be evaluated as evidence for assertions about the artifacts in t.history.10:44
persiaThis probably has implications about the reliability of any assertions (e.g. without any opinions including things like "this test passed", there probably isn't any evidence that constraints are met, which makes any claim based on constraints or intents indefensible).10:45
persiaBut it is still possible to make claims like "this work was done by Bob" from the proposals alone.10:45
persiaAnd t.history necessarily references proposals.10:45
*** traveltissues has joined #trustable10:46
persia(for histories based on mailing lists, one might provide a sequence of thread identifiers, where each thread consisted of a t.proposal and a collection of associated opinions (implemented as replies to the thread))10:47
*** toscalix_ has quit IRC10:50
*** toscalix__ has joined #trustable10:50
*** toscalix__ is now known as toscalix10:51
persiaThinking about it, I realise that the above may not make clear how to handle new proposals that may not have been evaluated according to policy.11:02
persiaAbstractly, one creates a speculative history with a looser policy that represents the artifacts that would exist if the proposal was evaluated, and then consumes that speculative history.  It is expected that any opinion produced is a result of the consumption of such a speculative history (and ideally one can identify from the content of the opinion how to reproduce the speculative history that caused the opinion), but such consumption does not11:05
persianecessarily have any effect on a policy-managed t.history (aside from the possibility that the opinion is eventually recorded when the associated t.proposal is evaluated).11:05
persiaAs a concrete example, if someone posts a patch to a mailing list, a reviewer might download the patch along with the release tarball for the release to which the patch applies, apply the patch, build it, run it, and then reply to the email containing the patch including a review.11:07
persiaIf someone else decides to include that patch in a later release, they might add the patch author and reviewer identity to a ChangeLog before creating the new release tarball.11:08
persiaSame process, different implementation is someone uploading a change to gerrit, someone fetching the change ID, building, running, and then commenting on gerrit and causing merge.  gerrit records the change ID in the commit message for the change (t.proposal), and stores the review (t.opinion) in NoteDB in such a way that the Change ID is sufficient to retrieve it.11:11
persiaIf someone later decides to tag the merge as a release, they might choose to rely on gerrit to already contain attribution for submitter and reviewer, and not include a ChangeLog entry.11:12
reiterativeThese are good illustrations, and clarifying that a t.proposal is in effect a speculative t.history makes it clearer. My concern is that we are not clearly expressing this in the current ontology. Adding some examples like this and tightening up the definitions should address that.11:14
reiterativee.g. We may need to explicitly state that all evidence must be part of the t.history, ee11:16
reiterativeacknowledging that this may mean that the scope of t.history may require a number of discrete, coordinated elements11:16
reiterativeIn my opinion, this isn't clear in the current ontology11:17
persiat.proposal is *not* a speculative t.history.11:17
persiaOne can construct a speculative t.history by adding a t.proposal to some history.11:17
persiaThis is effectively EVALUATE, but the result of that EVALUATE doesn't need to be any canonical "the" history, but can be a speculative one.11:18
persiaAnd if one does this speculatively, one may have different policy.11:18
locallycompactHow does this change with commutative patches11:19
persiaSome review systems will batch, effectively taking all the proposals made since the last batch, creating a speculative history with all of them atop the canonical history, and evaluating that.11:19
persialocallycompact: What do you mean by "commutative patch"?11:19
locallycompacta la
persiareiterative: t.history is *defined* as "a recorded sequence of evaluated proposals".  How much more explicit need we be that a history references proposals?11:20
locallycompactin pijul I'm not interested in a definitive or even particularly agreed history of changes, I'm interested in which patches I accept personally11:21
locallycompactand they can commute in that I can reorder them11:21
locallycompactI can take some things now, perhaps things that are newer in your history than you, and maybe take the rest of your history later, but maybe not11:21
locallycompact*than you/than others11:22
persialocallycompact: The link you provide doesn't have an easy way to find a definition of "commutative patch".11:22
persiaAh, but you explained :)11:23
persiaSo, yeah, doesn't matter.  With pijul one can implement workflows with a canonical history or workflows with personal histories, and create arbitrary speculative histories when considering patches.11:23
locallycompactok that makes sense11:24
persiaWhen a t.identity CONSUMEs a t.history, it will be one particular construction.11:24
persiaThat t.identity might also construct other t.histories, if they like, but that will probably involve them CONSUMEing lots of peer t.histories, SUBMITTNG local t.proposals for their private history, and then EVALUATING them into any t.history they wish to be CONSUMEd (either by themselves or by others, as a result of publication).11:25
persiaGiven my brief read from and your description, I suspect pijul as a tool has shortcuts that make this sequence of operations trivially easy to accomplish.11:26
persia(looks like one can have a single command to fetch a specific patch from a foreign branch and insert it into a local branch, combining all of CONSUME, SUBMIT, and EVALUATE)11:28
reiterativepersia: It's the relationship between t.opinion and t.history that isn't completely clear in the ontology. Plus I don't believe that we've described the events in sufficient detail.11:33
persiareiterative: It's transitive.11:38
persiat.opinion: an opinion expressed by a t.identity about a specific t.proposal11:39
persiat.history: a recorded sequence of evaluated t.proposals11:39
persiaHow EVALUATE is implemented is flexible.  Where EVALUATE includes information about opinions, we have access to those opinions.  Where it does not, we do not.11:40
persiaOr, for "we", perhaps replace "the t.identity that CONSUMEs the t.history"11:40
persiaThat not having access is inconvenient just makes implementations of EVALUATE that don't include information about opinions less likely to result in output that provides evidence to support claims.11:41
persiaBut there's no reason that a given process cares.11:42
persiaConsider the case where history is recorded in git, and the CI engine automerges a test report every once in a while, parented to a tested commit.11:42
persiaIn such a case, the opinion is implemented as a commit, and the test report might be considered evidence for claims about the parent commit.11:43
reiterativeAgreed. What this implies (but doesn't make completely clear) is that, in order for the opinion to be used as evidence, it needs to form part of the history.11:43
reiterativeOtherwise it can't be CONSUMEd11:44
persiaThe only way to access *any* information is CONSUME.  Only a history can be CONSUMEd.11:44
persiaTherefore, all information available as a result of CONSUME is necessarily in t.history11:45
reiterativeThat's the point we need to underline. It is possible to infer this from our current ontology, but I think we need to spell it out for the hard-of-thinking (like me).11:45
persiaThat t.history might be implemented as a collection of cross-linked blog posts, half of which can only be found on the wayback machine is an implementation detail.11:45
persiaI understand your point.  I'm not sure how that can be done without being proscriptive in some way.11:46
persiaI'm very leery of saying anything like "a t.opinion MUST be encoded in a t.history".11:47
persiaBecause I don't believe that to be true.11:47
persiaOn the other hand, if it isn't, it probably isn't available for audit.11:47
persiaIf it is available for audit in some form, then t.history necessarily expands to include whatever information source records that t.opinion.11:47
reiterativeAgreed. But we can say, in order to be CONSUMED as evidence, a t.opinion MUST be part of a t.history11:48
persiaI think that is easy to misread.11:48
reiterativePerhaps. I think that we can best clarify all of this by including some coherent descriptions of the Events.11:48
persiaMy fear is that someone thinks it implies particular implementation.  Previous discussions of that type led to a tool that mined history from gitlab and stored it as a sequence of git commits, which ended up not being useful to anyone.11:49
reiterativeAgain, some illustrative examples might help avoid this misconception11:50
persiaI previously wrote a narrative.  I'll paste here.  Maybe that would help if formally encoded somewhere (and maybe it needs adjustment):11:51
persia    Some IDENTITY SUBMITs some PROPOSAL consisting of a set of ARTIFACTS, which causes some (possibly empty) set of IDENTITYs to RECORD OPINIONs about the PROPOSAL.  The PROPOSAL and associated OPINIONs are EVALUATEd resulting in inclusion in a HISTORY, which may be arbitrarily truncated.  After inclusion, an IDENTITY may ASSERT a MARKER to any PROPOSAL in the HISTORY, such as to indicate that a particular point in history was assigned to some use or11:51
persia had some property not known at the time of evaluation.  a HISTORY is then CONSUMEd by an IDENTITY to perform some action (build, install, whatever) on the constituent ARTIFACTS (or possibly metadata of the HISTORY itself).11:51
persia    While not yet fully explored, the intent is to determine a common set of properties that might be expected to be available about each of the items and actions in capitals, and a common notation that could be consumed by tooling about what actually happened.  Whether an organisation chooses to preserve a copy of extracted evidence over time or forensically evaluate the tooling and data in situ at time of analysis becomes a choice while preserving11:51
persiacommonality of analysis tooling.11:51
persia    SOFTWARE is an abstract representation of code and/or data, which is only realised when instantiated into some SYSTEM, which may be entire or be composed of arbitrarily nested subSYSTEMs. Everything beyond highest level SYSTEM under consideration is considered CONTEXT, which may impose some external LIMITs on the total capabilities of the system (where these might include things like the laws of physics, but might also include other factors11:52
persiabeyond the control of the producing supply chain (including affiliates, suppliers, customers, etc.)).11:52
persia    The precise separation of SYSTEM and CONTEXT is based on the organisations INTENT: how the organisation decrees the SYSTEM should behave.  As INTENT is usually written somewhat vaguely, analysis is performed to develop a set of CONSTRAINTs from the INTENT, where each CONSTRAINT is explicitly verifiable.  The total set of LIMITs and CONSTRAINTs describe the scope of SYSTEM behaviour within the CONTEXT.  Note that there is no expectation that11:52
persiaSOFTWARE was developed with the same INTENTs applied to a SYSTEM consuming the SOFTWARE: it is sufficient that the SYSTEM that is the instantiation of the SOFTWARE has behaviour matching the INTENT.11:52
persia    The creation of a SYSTEM is described by some PROCESS, consisting of both descriptions of data flows and specific POLICY governing how to EVALUATE a PROPOSAL for each specific HISTORY in the PROCESS.  The actual creation of a SYSTEM is done by some PRACTICE, where conformance to PROCESS or compliance to POLICY may be analysed by consideration of evidence in each HISTORY covered by the PROCESS.11:52
persiaDoes that sort of text help address your concerns?11:52
reiterativeYes, telling a story helps to provide valuable context.13:46
reiterativeAre you happy for me to take this and add it as an introduction to Might need a little tweaking, but probably better to do that via a review process.13:54
persiaYes, please.14:23
persiaI know there are issues with it (e.g. a PROPOSAL describes a set of ARTIFACTS, rather than consisting of ARTIFACTS), but the act of writing it helped me understand the terms, and suitably refined, I hope it would help others.14:24
persiaOh, actually, those belong separately as introductions to and, really.16:36
*** toscalix has quit IRC16:49
*** traveltissues has quit IRC19:21
*** traveltissues has joined #trustable22:28
*** traveltissues has quit IRC22:31

Generated by 2.15.3 by Marius Gedminas - find it at!