| *** toscalix has joined #trustable | 08:45 | |
| *** toscalix has quit IRC | 08:46 | |
| *** toscalix_ has joined #trustable | 08:47 | |
| reiterative | persia: 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 |
|---|---|---|
| persia | I am saying that,. | 10:06 |
| persia | I also don't understand how t.proposal sits outside t.history. | 10:06 |
| reiterative | It may be a patchset on a mailing list | 10:07 |
| persia | Either t.proposal sits atop a speculative history or t.proposal forms a new history, at the time of creation. | 10:07 |
| persia | A patchset on a mailing list sits atop a speculative history. | 10:07 |
| persia | Similarly, t.opinion is about a patchset, so associated with that patchset in history. | 10:08 |
| persia | There 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 |
| persia | If 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 |
| persia | But those are implementation details. | 10:10 |
| reiterative | Yes, 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 definition | 10:11 |
| reiterative | I don't think it is at present | 10:11 |
| reiterative | It also has clear implications for the integrity of the t.histoiry if some implementations of t.history may involve the coordination of several discrete elements | 10:12 |
| persia | As a matter of record, a "git repository" is organised as a set of discrete elements :) | 10:33 |
| persia | That said, I don't know why it matters. A t.history is the (possibly collective) set of things that is CONSUMEd. | 10:34 |
| persia | I 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 |
| persia | From git, "t.history: a recorded sequence of evaluated t.proposals". I'm not sure how this implies any coherency to the sequence. | 10:38 |
| persia | From 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 |
| persia | Implementing as a list of messageID+SHA256 of message probably even provides a fair degree of protection from tampering. | 10:39 |
| persia | Oh, and I don't think there is any sort of MUST about opinions. | 10:43 |
| persia | If 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 |
| persia | This 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 |
| persia | But it is still possible to make claims like "this work was done by Bob" from the proposals alone. | 10:45 |
| persia | And t.history necessarily references proposals. | 10:45 |
| *** traveltissues has joined #trustable | 10: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 IRC | 10:50 | |
| *** toscalix__ has joined #trustable | 10:50 | |
| *** toscalix__ is now known as toscalix | 10:51 | |
| persia | Thinking 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 |
| persia | Abstractly, 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 not | 11:05 |
| persia | necessarily 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 |
| persia | As 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 |
| persia | If 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 |
| persia | Same 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 |
| persia | If 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 |
| reiterative | These 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 |
| reiterative | e.g. We may need to explicitly state that all evidence must be part of the t.history, ee | 11:16 |
| reiterative | acknowledging that this may mean that the scope of t.history may require a number of discrete, coordinated elements | 11:16 |
| reiterative | In my opinion, this isn't clear in the current ontology | 11:17 |
| persia | t.proposal is *not* a speculative t.history. | 11:17 |
| persia | One can construct a speculative t.history by adding a t.proposal to some history. | 11:17 |
| persia | This 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 |
| persia | And if one does this speculatively, one may have different policy. | 11:18 |
| locallycompact | How does this change with commutative patches | 11:19 |
| persia | Some 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 |
| persia | locallycompact: What do you mean by "commutative patch"? | 11:19 |
| locallycompact | a la https://pijul.org/ | 11:20 |
| persia | reiterative: 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 |
| locallycompact | in pijul I'm not interested in a definitive or even particularly agreed history of changes, I'm interested in which patches I accept personally | 11:21 |
| locallycompact | and they can commute in that I can reorder them | 11:21 |
| locallycompact | I 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 not | 11:21 |
| locallycompact | *than you/than others | 11:22 |
| persia | locallycompact: The link you provide doesn't have an easy way to find a definition of "commutative patch". | 11:22 |
| persia | Ah, but you explained :) | 11:23 |
| persia | So, 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 |
| locallycompact | ok that makes sense | 11:24 |
| persia | When a t.identity CONSUMEs a t.history, it will be one particular construction. | 11:24 |
| persia | That 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 |
| persia | Given my brief read from pijul.org 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 |
| reiterative | persia: 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 |
| persia | reiterative: It's transitive. | 11:38 |
| persia | t.opinion: an opinion expressed by a t.identity about a specific t.proposal | 11:39 |
| persia | t.history: a recorded sequence of evaluated t.proposals | 11:39 |
| persia | How 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 |
| persia | Or, for "we", perhaps replace "the t.identity that CONSUMEs the t.history" | 11:40 |
| persia | That 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 |
| persia | But there's no reason that a given process cares. | 11:42 |
| persia | Consider 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 |
| persia | In 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 |
| reiterative | Agreed. 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 |
| reiterative | Otherwise it can't be CONSUMEd | 11:44 |
| persia | The only way to access *any* information is CONSUME. Only a history can be CONSUMEd. | 11:44 |
| persia | Therefore, all information available as a result of CONSUME is necessarily in t.history | 11:45 |
| reiterative | That'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 |
| persia | That 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 |
| persia | I understand your point. I'm not sure how that can be done without being proscriptive in some way. | 11:46 |
| persia | I'm very leery of saying anything like "a t.opinion MUST be encoded in a t.history". | 11:47 |
| persia | Because I don't believe that to be true. | 11:47 |
| persia | On the other hand, if it isn't, it probably isn't available for audit. | 11:47 |
| persia | If it is available for audit in some form, then t.history necessarily expands to include whatever information source records that t.opinion. | 11:47 |
| reiterative | Agreed. But we can say, in order to be CONSUMED as evidence, a t.opinion MUST be part of a t.history | 11:48 |
| persia | I think that is easy to misread. | 11:48 |
| reiterative | Perhaps. I think that we can best clarify all of this by including some coherent descriptions of the Events. | 11:48 |
| persia | My 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 |
| reiterative | Again, some illustrative examples might help avoid this misconception | 11:50 |
| persia | I previously wrote a narrative. I'll paste here. Maybe that would help if formally encoded somewhere (and maybe it needs adjustment): | 11:51 |
| persia | Elements: | 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 or | 11: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 preserving | 11:51 |
| persia | commonality of analysis tooling. | 11:51 |
| persia | Concepts: | 11:52 |
| 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 factors | 11:52 |
| persia | beyond 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 that | 11:52 |
| persia | SOFTWARE 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 |
| persia | Does that sort of text help address your concerns? | 11:52 |
| reiterative | Yes, telling a story helps to provide valuable context. | 13:46 |
| reiterative | Are you happy for me to take this and add it as an introduction to elements.md? Might need a little tweaking, but probably better to do that via a review process. | 13:54 |
| persia | Yes, please. | 14:23 |
| persia | I 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 |
| persia | Oh, actually, those belong separately as introductions to elements.md and concepts.md, really. | 16:36 |
| *** toscalix has quit IRC | 16:49 | |
| *** traveltissues has quit IRC | 19:21 | |
| *** traveltissues has joined #trustable | 22:28 | |
| *** traveltissues has quit IRC | 22:31 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!