| *** traveltissues has joined #trustable | 05:27 | |
| *** willbarnard has joined #trustable | 07:52 | |
| *** sambishop has joined #trustable | 08:25 | |
| *** willbarnard has quit IRC | 08:46 | |
| *** willbarnard has joined #trustable | 08:53 | |
| *** willbarnard has quit IRC | 09:13 | |
| *** willbarnard has joined #trustable | 09:13 | |
| willbarnard | persia: the gate definition you provided describes a single gated step before merge. Our Gate role definition is more detailed, we describe a series of gated steps, the final one of which is the gate to merge. | 14:31 |
|---|---|---|
| persia | The definition I linked assumes a model where there may be an arbitrary number of merges prior to completion of all relevant pipelines. | 14:32 |
| persia | The contrast you mention suggests a definition of "merge" as a final action. Am I confused? | 14:32 |
| willbarnard | In our model there will be an arbitrary number of merges, within each merge pipeline there are a number of gating decisions | 14:35 |
| persia | I think I have to read your definitions more in order to have this conversation. | 14:36 |
| persia | Essentially "merge pipeline" is meaningless to me, which complicates any response :) | 14:36 |
| persia | It may be that what I call "review" is part of what you call "gate", when that review happens to be performed by an automated system. | 14:37 |
| willbarnard | Not exactly, in our model review is an operation conducted by the Reviewer role (a human), there is also validation which may be performed by an automated system and includes test, static code analysis, etc. | 14:39 |
| persia | Right. That differs significantly from the model last time I was following trustable closely, which made no distinction over the class of intelligence performing a review. | 14:40 |
| paulsherwood | persia: do you see problems in what willbarnard is describing? | 14:41 |
| persia | I think asserting that humans are incapable of performing tests or static analysis is somewhat limiting. I also think that whether an organisation chooses to emplace humans or robots for various roles is properly a policy decision to be taken by that organisation, rather than being something that should be encoded in a best practices standard. | 14:42 |
| persia | Aside from that, I think I don't understand the assertions being made well enough to have an opinion. From the definitions I understood previously, I would say things are wrong, but if the semnatics have changed, that opinion is potentially invalid. | 14:42 |
| willbarnard | Sure that is exactly what we have said, the Validator role may be automated or manual | 14:43 |
| persia | As an example supporting the idea that my opinions are based on incorrect definitions :) | 14:43 |
| willbarnard | In many cases there will be a combination of both types of validation | 14:44 |
| persia | (or at least non-current definitions: the ones I'm using match those discussed at a recent conference about CI and CD technologies) | 14:44 |
| paulsherwood | willbarnard: i think the Reviewer role may also be automated or manual... | 14:50 |
| willbarnard | That is a little different than we have defined, possibly your definition of review differs, what are the automated tasks that you include in your definition of review? | 14:52 |
| paulsherwood | where is our current definition of review? | 14:54 |
| persia | Frustratingly, starting from trustable.io, I had trouble finding the repo in which the definitions live, but more frustratingly, https://lists.veristac.io/cgi-bin/mailman/listinfo/trustable-software had an error, which someone probably wants to investigate. | 14:54 |
| paulsherwood | where did you get that link from? we moved to trustable.io a long time ago | 14:55 |
| paulsherwood | https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software | 14:55 |
| willbarnard | I don't recall that we have a formal definition of review | 14:56 |
| paulsherwood | let's fix that, then | 14:56 |
| persia | paulsherwood: Linked from https://trustable.gitlab.io/contributing.html | 14:56 |
| paulsherwood | persia: iiuc you are hinting that review can be automated? | 14:56 |
| persia | It depends on how you define "Review". | 14:56 |
| willbarnard | I suspect that what persia is calling review we are calling validation | 14:57 |
| persia | I believe that most sorts of review can be automated. There exist a set of things that are very hard to automate, some of which some folk call "review". | 14:57 |
| persia | willbarnard: I don't believe we have the same definitions at all: it's not just a matter of using different words. This is not a "lift" vs. "elevator" sort of situation, but rather "escalator" vs. "staircase" sort of situation. | 14:58 |
| willbarnard | possibly, could you give an example of the automated review tasks so we can be clear what we are talking about? | 14:59 |
| persia | I do not understand how that provides clarity, as you are asking for tasks without providing a definition. | 15:01 |
| persia | If I consider process compliance review, then checking the status of different votes of different classes as a result of other activity would be a review activity suitable for automation. | 15:01 |
| persia | If I consider code review, checking the status of the code against one or more code standards documents would be a review activity suitable for automation. | 15:01 |
| persia | I could go on, but without a shared understanding of "review", I don't think such a list has much value. | 15:02 |
| paulsherwood | persia: i think it does have value... | 15:02 |
| persia | I remember there being some document that specified what words mean, but I cannot find it in the git repos that are linked from trustable.io nor in the content available from there. | 15:02 |
| paulsherwood | (not least because it may help us to get to a useful definition) | 15:02 |
| persia | paulsherwood: Why? | 15:02 |
| paulsherwood | see above | 15:03 |
| persia | I'd rather start from a draft definition :) | 15:03 |
| persia | Yes: timing :) | 15:03 |
| paulsherwood | https://gitlab.com/trustable/workflow/blob/master/markdown/basics.md | 15:03 |
| willbarnard | in the case of the automated checking of code against standards, we have explicitly defined that as a task performed by the validator, any review of the output by a human is review | 15:03 |
| paulsherwood | https://gitlab.com/trustable/workflow/blob/master/markdown/roles.md | 15:03 |
| persia | Before this conversation, my definition of review was "an action consuming a candidate and resulting in a vote about the candidate". | 15:03 |
| paulsherwood | persia: patches welcome | 15:04 |
| persia | Well, yes, eventually I wil find a way to participate with the tooling. So far, my experience consists of about 5 attempts to register an account, each of which was stopped after 3-5 hours. | 15:04 |
| persia | Until then, I shall comment about things if asked, but maybe not produce patches. | 15:04 |
| willbarnard | from what you have said, I am fairly sure we are talking about the same thing, but we have defined those automated tasks as validation, they produce a result that can be reviewed | 15:05 |
| persia | and with those definitions, I understand the confusion about "Gate": that's clearly heavily overloaded. | 15:06 |
| paulsherwood | what stopped your attempts? | 15:06 |
| persia | willbarnard: That implies review by a human | 15:06 |
| willbarnard | yes, we have considered review to be a human task | 15:06 |
| persia | paulsherwood: Usually a sense that I had wasted yet another day attempting to register. | 15:06 |
| persia | willbarnard: Right. IF "review" is a human task, then no review activity can be automated. | 15:07 |
| persia | Which causes us to categorise all activities that can be automated as other than "review". | 15:07 |
| persia | And in such a semantic model, my list of automatable review activities is empty. | 15:07 |
| * paulsherwood guesses that persia didn't actually spend multiple 5-hour sessions working on registration attempts | 15:07 | |
| persia | paulsherwood: You hav e guessed wrong. | 15:08 |
| paulsherwood | lol | 15:08 |
| persia | To be fair, some of them were only three. Last tuesday was 5. | 15:08 |
| paulsherwood | what is the actual difficulty? most people appear able to register more easily | 15:09 |
| persia | Sometimes it's waiting indefinitely to receive any mail from gitlab. Sometimes it is gitlab telling me the links they have sent are invalid. Once I managed to get a password entry accepted, but changing my password (required on first login) put me in a state where I could neither log in nor cause a response from the "forgot password" link. | 15:10 |
| persia | Currently, I'm not trying because my email client provider recently changed policy, requiring acceptance that they had permission to store all my email on their server. I refused such permission, so am between mail clients capable of dealing with my volume of email. | 15:11 |
| persia | (and gitlab doesn't have a mechanism to authenticate to an account without round-trip email) | 15:11 |
| persia | willbarnard: So, yeah, after reviewing the current definitions, my feeling is that "Gate" is a massively overloaded term. It seems to be some bit of software that checks conditions (from a variety of sources) and precipitates actions. | 15:17 |
| willbarnard | Yes, that is its role | 15:18 |
| persia | I suspect that some refactoring of the various things it does into categories (so, having "t.conditions" that would be a conflation of available data sources and "t.actions" that is a conflation of actions performed, or similar) would make for a simpler defintion. | 15:18 |
| persia | I agree that with that defintion of "gate", gating and merging are unrelated. | 15:19 |
| persia | I'm not delighted with that meaning being attached to the "gate" word, as to me, "gate" is soemthing that allows something to move from one state to another state in some state machine that defines the progressoin of code, which typically involves a "merge" operation. | 15:19 |
| willbarnard | We have tried to separate the roles. In practice many tools actually perform more than one role. | 15:19 |
| persia | I feel it is important to either explicitly declare such conflation or to avoid the conflation. | 15:20 |
| willbarnard | I would certainly agree with that | 15:21 |
| persia | Implicit conflation often leads to confusion. There are times when it does not, but my experience is that humans aren't careful about managing the semantic variance between homonyms. | 15:21 |
| persia | For instance, if I say "I'm off to have a row", it requires a farily deep knowledge of me to determine what I'm doing next. | 15:21 |
| persia | Some folk would be surprised if I headed out the door to find a counterparty. Others would be surprised to find me hunting around for my boat shoes. | 15:22 |
| willbarnard | persia: I am reluctant to add more t. definitions. But how about I add a state machine for the Gate to show the state progression, do you think that would help to clarify the role? | 15:32 |
| persia | No, actually. I think that would overreach. | 15:33 |
| persia | In my opinion, the definition of the state machine is properly a policy determination to be made by the implementing organisation. | 15:33 |
| persia | I think that the overarching model should support every potential development model from one-person-does-everything-when-they-feel-like-it to detailed approvals processes including a need for an auditor to approve that the appropriate reviews, validation, and approvals have happened in order for the software to progress. | 15:35 |
| willbarnard | that is what the policy handler does in our model | 15:36 |
| persia | In terms of definitions, my first opinion from looking at them is that there are too many. | 15:36 |
| willbarnard | the t.definitions? | 15:36 |
| persia | Which is what the policy handler does? | 15:36 |
| persia | Yes. I think there is unevenness in the semantics, and that the semantics would benefit from a refactor. My hope is that this would result in fewer definitions. | 15:37 |
| willbarnard | supports a range of different policies that are organization defined | 15:37 |
| willbarnard | I agree, I made a first pass at that so have removed quite a number already | 15:38 |
| persia | So, reading that definition, I do not understand why "Product Policy Handler" is defined. | 15:38 |
| persia | How does it differ from "Validator"? | 15:38 |
| willbarnard | validator performs the validations | 15:38 |
| willbarnard | e.g. run tests, lint, etc. | 15:39 |
| persia | So, operationally, if I look at the defintiions of "Gate", "Validator", and "Product Policy Handler", I don't see the difference between "Validator" and "Product Policy Handler". | 15:40 |
| persia | Unless "Product Poilicy Handler" is always human (whereas I think it is a trivially automatable role) | 15:40 |
| willbarnard | the policy handler looks at the conditions required by the project policy | 15:41 |
| persia | How is "looks at" defined? | 15:41 |
| willbarnard | e.g. what type of approvals are needed, what tests results are required, etc. | 15:41 |
| willbarnard | takes the policy configuration and policy data as inputs and produces a binary result | 15:42 |
| persia | I presume that is a definition of "conditions". | 15:42 |
| persia | How does it produce the binary result? Does it perform a test? | 15:42 |
| willbarnard | not a test of the t.software but a test of the policy conditions, yes | 15:43 |
| persia | t.test isn't domain-restricted. | 15:44 |
| willbarnard | I think should be otherwise every if statement in the code would be a t.test which is clearly nonsense | 15:45 |
| persia | So, either the product policy handler and the validator are the same *OR* t.test needs to be defined more closely. | 15:45 |
| persia | How do you get there? | 15:46 |
| willbarnard | I would certainly like to see t.test more tightly defined | 15:46 |
| persia | t.test is mapped to t.requirement, executes in t.ernvironment, and produces t.evidence. | 15:46 |
| persia | It is possible to have conditional statements in code that don't meet that definition. | 15:46 |
| willbarnard | The t.test definition is missing the actual definition of what a test is | 15:48 |
| persia | Tightening the definitions is one way to approach the problem. The difficulty with doing so is that it ends up creating more definitions (as you need to separately define all that is excluded as a different noun). | 15:48 |
| persia | My read of the current definition of t.test is that a test can be *anything* that has the right inputs and outputs. | 15:49 |
| persia | So implicitly includes "integration testing suites", "behaviour testing" models, physical manipulation of a device on which the software is installed to observe results (e.g. automotive roll testing), or anything else that is needed by the implementing organisation. | 15:50 |
| persia | A fairly common example of t.test that resists close definition is user testing, wherein software is made available to users who report whether the current state is acceptable. | 15:50 |
| willbarnard | well I think we should explicitly say that it exercises t.software | 15:51 |
| persia | Why? That forces the definition of "Product Policy Handler", and also requires some equivalience of t.test for policy compliance. | 15:51 |
| willbarnard | not sure I follow | 15:52 |
| persia | So, if we assert t.test covers anything that executes in t.environment and produces t.evidence, we can remove "Product Policy Handler" as it is merely a repetition of "Validator". | 15:53 |
| persia | If we assert t.test does not cover testing policy compliance (as that is different), then we need something new for the "Product Policy Handler" to execute. | 15:54 |
| persia | Currently there is no noun for the check performed by the "Product Policy Handler". | 15:54 |
| persia | This represents semantic inconsistency, which can be solved either way. | 15:54 |
| willbarnard | Not at all, the policy compliance handler is implementing the policy compliance check | 15:54 |
| persia | Which is defined as which term on https://gitlab.com/trustable/workflow/blob/master/markdown/basics.md ? | 15:55 |
| willbarnard | one of the many things that are not defined on that page | 15:57 |
| persia | In that case, I think we agree. The "Product Policy Handler" has no noun, which is a semantic inconsistency. | 15:57 |
| persia | I suggest that the inconsistency can be resolved either by adding such a noun or removing "Product Policy Handler", and dealing with policy with the "Validator". | 15:58 |
| persia | My preference is for the latter, simply in the interest of simplifying the semantics, but from this discussion, I think your preference is for the former. I'm curious what value you perceive to be associated with the former that suggests the larger semantic model. | 16:01 |
| willbarnard | We may need to add something there, but the policy handler is certainly different to the validator and needs to run after all the validators have finished | 16:01 |
| persia | Please explain both of these points. I do not agree with either at face value. | 16:01 |
| willbarnard | The policy may depend upon the results of all the validations, in addition to approvals which may only be performed after validation | 16:03 |
| persia | I am willing to stipulate that the Product Policy Handler can only achieve a positive result if run after all other activities are complete. Why can it not be run in advance (and fail)? | 16:05 |
| persia | In other context, I typically see that role being executed on every modification to a t.change | 16:05 |
| willbarnard | Kinnison: I have made some changed in MR!28 which hopefully covers the points you raised last week | 16:05 |
| persia | Conversely, if we can only run the Product Policy Handler when we expect a successful result, how do we check if it can be run? How does that check differ from the check performed by the Product Policy Handler? | 16:06 |
| willbarnard | yes, on every t.change | 16:06 |
| * persia reviews the t.change definition again | 16:07 | |
| persia | No, not every t.change, every modification of a t.change | 16:07 |
| willbarnard | there is no such thing as a modification of a t.change | 16:07 |
| persia | Um, then I'm really confused. | 16:07 |
| willbarnard | we model all inputs as a series of t.changes | 16:08 |
| persia | For me, a change is a submitted suggestion of something that the submitter expects to be changed. | 16:08 |
| willbarnard | think of t.change as a single commit | 16:08 |
| persia | As it moves through process, the submitter may change their mind, and change the t.change. | 16:08 |
| persia | If that isn't permitted, I cannot understand why any submitter would ever submit a change. | 16:08 |
| persia | Yes. t.change is a commit. | 16:08 |
| willbarnard | every time you commit you create a t.change | 16:08 |
| Kinnison | I imagine it depends on whether you think of a t.change as something which has been proposed, or something which has been accepted | 16:09 |
| persia | Yes. | 16:09 |
| persia | Given that it is input to t.test, I consider it something that is proposed. | 16:09 |
| willbarnard | so a set of t.changes produced the currect status | 16:09 |
| willbarnard | current | 16:09 |
| Kinnison | if you think of t.change as immutable, a proposed t.change still can't change, but it could be replaced with a different t.change | 16:09 |
| Kinnison | Which, at a superficial level, you could think of as 'changing the t.change proposed' | 16:09 |
| persia | Ah. If we want immutable t.change, we should include that in a definiton. | 16:09 |
| Kinnison | As I describe it just there ^^ is basically gerrit | 16:10 |
| persia | I would prefer to be able to capture the review history over several revisions of t.change, where there is a lower-level immutable construct, but I'm happy to have a new word for the higher-level construct, if others prefer. | 16:10 |
| Kinnison | For gerrit, a changeid can be applied to multiple different commits (t.change) one of which is the one proposed for merging at any given point in time | 16:10 |
| willbarnard | the gerrit/notedb definition is a little different, they define a Change and an aggregation of an aggregation of commits | 16:11 |
| * Kinnison has no idea what the appropriate wording would be | 16:11 | |
| persia | Yes. I think both constructs are useful to define, so we have the individual commit (immutable), and the current revisoin of that commit (mutable), where we only consider the latter at higher levels. | 16:11 |
| persia | willbarnard: It's not just a tooling thing. I can force-push a merge-request/pull-request with other tooling and preserve the higher-level construct (the thing under review) while replacing the lower level construct (the immutable commits). | 16:12 |
| persia | Key is that there are two things here. One is immutable, and the other is mutable. | 16:12 |
| persia | If we want to capture the difference, we need a new noun. If we don't care about the difference, I assert t.change is mutable. | 16:13 |
| willbarnard | well I think that comes down to policy | 16:15 |
| persia | How do you mean? | 16:15 |
| willbarnard | if you want to squash the commits on merge | 16:15 |
| persia | Rather, I have trouble imagining an organisation that would declare that developers could not revise code that was found deficient in a review/validation process. | 16:16 |
| persia | squash/non-squash is irrelevant. | 16:16 |
| * Kinnison thinks willbarnard and persia are talking slightly across from one another. | 16:17 | |
| Kinnison | willbarnard: persia is interpreting 't.change' as a merge *request* | 16:17 |
| * persia knows this to be true | 16:17 | |
| willbarnard | Kinnison: my question is whether it is clearer to you with the changes I have made | 16:17 |
| Kinnison | willbarnard: If that's not meant to be the case, then such a thing needs a t.whatever | 16:17 |
| Kinnison | I've not read the MR yet, been busy with other things | 16:17 |
| persia | Kinnison: I'm trying very hard to interpret t.change precisely as described at https://gitlab.com/trustable/workflow/blob/master/markdown/basics.md : I only consider a merge-request to be an example of that. | 16:17 |
| Kinnison | then got distracted with this conversation | 16:17 |
| willbarnard | no rush, just letting you know there is an update | 16:17 |
| Kinnison | persia: Aaah I interpret the t.change from that document as a commit | 16:18 |
| willbarnard | yes, the t.change definition is basically a single commit | 16:18 |
| persia | Kinnison: I think the document doesn't clearly indicate whether either of us is correct. | 16:18 |
| willbarnard | we will run the gate for each t.change submission | 16:18 |
| willbarnard | the policy will fail until the set of changes is ready for merge | 16:19 |
| Kinnison | persia: Given that this discussion could happen at all, I believe you are correct - there is ambiguity | 16:19 |
| persia | willbarnard: I consider those statements true for either mutable or immutable t.change. | 16:19 |
| willbarnard | The is certainly room for improvement in the wording | 16:19 |
| persia | I'm not convinced there is a problem with the wording. | 16:19 |
| persia | I agree that the wording does not require immutability. I'd be against adding another term unless someone explains why we care. | 16:20 |
| * persia likes small vocabularies | 16:20 | |
| persia | Or, to put it another way, I do not agree that the fact that the wording does not require immutability should be considered a bug. | 16:20 |
| willbarnard | in the case that a t.change is reverted then surely we just have two t.changes and a final state that is the same as an earlier state | 16:21 |
| persia | What? Firstly, I don't see a definition of "revert". Secondly, why would something be reverted except by application of a new t.change with opposite effect? | 16:21 |
| willbarnard | at the time the the policy passes we only care about the result of the set of changes not the intermediate states | 16:22 |
| persia | That runs counter to the common arguments I hear about having a true history. I support the idea of fictional history. | 16:22 |
| persia | I'm not sure what value we have if all history is fictional though. | 16:22 |
| willbarnard | again that is a policy decision, I don't think we should mandate a specific policy | 16:23 |
| willbarnard | there is certainly a strong case for some careful tidy up | 16:23 |
| persia | Although I often claim various things are policy decisions, I really don't think we should consider whether t.evidence is fictional as a policy decision. I think that defeats the point of the initiative entirely. | 16:23 |
| persia | If there is not a standard of evidence that would cause it to be trusted, how can the result be trustable? | 16:24 |
| willbarnard | the view we have taken is that the evidence generated on the commit that is merged is the one we care about | 16:25 |
| persia | merged to which tree? | 16:26 |
| willbarnard | mainline | 16:26 |
| willbarnard | although branching strategy is a policy decision | 16:26 |
| persia | Which is where in the process? Is that what runs in production? What is tested for very expensivce tests? Something accepted by an broad community after testing in production for many months? | 16:26 |
| willbarnard | you will notice there is nothing yet in the t.defintions for t.release, although strangely we do have a t.update... | 16:27 |
| persia | I believe that is correct. I believe "release" has no meaning in a software development context. | 16:29 |
| persia | The importnat time is when the software is changed in production. Someone publishing a website doesn't affect anything. | 16:29 |
| willbarnard | absolutely, that would be my definition of release | 16:30 |
| persia | Which is your definition of release? | 16:31 |
| willbarnard | the build that is released to production | 16:31 |
| persia | For which production instance? | 16:31 |
| persia | I assert that for successful software there are so many production instances that they cannot usefully be tracked by the development group. | 16:32 |
| persia | Whereas it does become possible to track potential updates, which may be applied by others at the time of their convenience. | 16:32 |
| willbarnard | well they could be flashed in the factory, updated in the field, it depends on the type of software | 16:33 |
| willbarnard | for the type of software that requires the trustable approach there are probably some long running compliance tests that need to be executed on that build | 16:34 |
| persia | I agree on compliance. I agree on multiple ways to update software. I assert that all software in use requires field updates to be secure. | 16:35 |
| persia | Sadly, this means that I expect nearly all software subject to compliance review will have demonstrable insecurities at the time of update. | 16:35 |
| Kinnison | willbarnard: !28 looks like it addresses the direct concerns I had last week | 16:36 |
| persia | Anyway, we were looking at whether we needed a t.release. Given that t.update seems to imply a delta between one state and another, shall we agree that t.release represents some state of software that is installed in production? | 16:37 |
| persia | Or, more formally: t.release * is a t.artefact * is installed in t.environment * is expected to be used for non-validation tasks | 16:38 |
| willbarnard | yes, that is my view | 16:38 |
| persia | Oh, we probably also want * a t.release must be uniquely identifiable | 16:39 |
| willbarnard | yes, we will need to few specifics for it | 16:39 |
| persia | Now, just to confirm we really need this word: what does it give us that we do not get from t.artefact | 16:39 |
| persia | Alternately put, would it make as much sense to implement t.release by replacing every string of "t.artefact" with "t.release"? | 16:41 |
| willbarnard | is it a t.artefact or a t.software? | 16:41 |
| persia | heh. | 16:42 |
| persia | I think it is t.artefact, because t.artefact is defined as having been constructed (so suitable for use), whereas t.software appears to be unconstructed. | 16:42 |
| willbarnard | the difference is that there are likely to be different policy criteria that apply to a t.release | 16:43 |
| persia | But I admit to not understanding why either t.build or t.sourcecode exist with that interpretation of t.software | 16:43 |
| willbarnard | I dont think that was the original intention of the t.software definition | 16:43 |
| willbarnard | t.build is a little different | 16:44 |
| persia | Are you comfortable with the statement that every t.release is a t.artefact, but not every t.artefact has processed through the pipelines sufficiently to be a t.release?_ | 16:44 |
| willbarnard | t.sourcecode (I would prefer t.source) is meant to be the unconstructed t.change | 16:45 |
| persia | Yes, but I need a *collection* of t.changes to have something from which I can construct an artefact. | 16:45 |
| persia | I can't use a single t.change: it is only meaningful in the context of the history of all changes. | 16:46 |
| willbarnard | that is true, unless you write the whole system in one commit | 16:46 |
| willbarnard | My only question about your statement is whether we should use t.software rather than t.artefact | 16:47 |
| persia | Heh, right, but then when I update it, my next "release" needs to be a t.artefact from t.software, as I can only do that once :) | 16:47 |
| persia | As much as I dislike the orthography, I think t.artefact is expressly defined as being the thing that is released and/or installed into a t.environment that is intended for use. | 16:48 |
| willbarnard | doesnt that depend on whether we have a partial update | 16:48 |
| persia | I do not read the definition of t.software in a way that permits it to be so installed in t.environment. | 16:48 |
| willbarnard | do we need the t.software definition? | 16:48 |
| persia | Note that I'm open to conflating t.artefact and t.softeare if that makes more sense. My feeling is that it only makes sense for a narrow subset of implementation mechanisms for t.software | 16:48 |
| persia | I think so, as we need a source input from which to create t.artefact | 16:49 |
| willbarnard | I think the source input is t.sourecode | 16:49 |
| persia | I also don't see any useful difference between t.software and t.sourcecode | 16:49 |
| persia | I like the definition of t.software better than the definition of t.sourcecode. I suggest that t.sourcecode be removed from the vocabulary. We can rename t.software to t.source or t.sourcecode as a follow-up operation. | 16:50 |
| willbarnard | then there is a case for removing t.software but I would like to hear the view of the original author of that | 16:50 |
| persia | Is the original author in-channel? | 16:51 |
| persia | Wait, hrm? What case for removing t.software? | 16:51 |
| persia | I agree with renaming it. I cannot agree with removing it. Nothing else serves as a container for the set of t.changes. | 16:51 |
| willbarnard | It is the container for t.changes and the link to t.requirements | 16:53 |
| willbarnard | if we use t.artefact then the t.release could be a t.artefact or a collection of t.artefacts | 16:55 |
| persia | Right, so I think we need t.software. I'm open to renaming it. You wrote "then there is a case for removing t.software". I'd like to read that case. | 16:55 |
| persia | To meet the requirement that a t.update be atomically applicable, I think we need t.release to represent such a collection of t.artefacts | 16:56 |
| persia | Unless we only have t.update and don't bother with t.release at all. | 16:56 |
| willbarnard | I am wondering what the original intended meaning of t.software was | 16:56 |
| willbarnard | or we have t.release and don't bother with t.update at all | 16:57 |
| persia | I think t.software was intended as a noun to represent a collection of t.changes and link to t.intents, t.requirements, t.metrics, and t.evidence | 16:57 |
| persia | Personally, I'd prefer if t.software was only a collection of t.changes and t.evidence, with t.intents and t.requirements being controlled by t.changes and t.metrics being part of t.evidence, but there's lots of discussion to be had to determine if that would be consistent. | 16:58 |
| persia | Anyway, regardess of how we define t.software, let's look more closely at whether we need t.release. | 17:00 |
| willbarnard | should that be is a collection or has a collection? | 17:00 |
| persia | For me, that's a phisophical question akin to "do we define a human as a collection of cells or as having a colleciton of cells" | 17:01 |
| persia | In practice, I think it doesn't matter that much. I tend to use "is" in such contexts, but I don't mean "is" in a limiting way. | 17:01 |
| willbarnard | well the data relationship is different, but we can look later how to improve that wording | 17:02 |
| persia | Could you explain how you think the data relationship is different? | 17:02 |
| willbarnard | I would be happy to define t.release as an aggregation of t.artefacts | 17:04 |
| willbarnard | we just need to define those specific conditions that define a specific aggregation as forming a t.release | 17:05 |
| persia | So, what is the distinction between t.release and t.update. Remember that we cannot "install a release" and be consistent with the requirements of t.update. | 17:06 |
| willbarnard | it depends how we want to define it | 17:12 |
| willbarnard | but the restrictions we apply to aggregation of t.artefacts that form a t.release should also apply to those that form a t.update | 17:14 |
| willbarnard | there may be additional conditions that we want to apply to t.update that are not applicable to t.release | 17:14 |
| persia | Yes. What I'm wondering is whether t.update covers enough that we don't need t.release. | 17:14 |
| persia | My assertion is that if we do not have any specific differentiators, we should not have a new word. | 17:15 |
| willbarnard | I don't believe the current definition does | 17:15 |
| persia | Would you agree that t.release is a collection of t.artefacts and a t.update is based on t.release? | 17:15 |
| willbarnard | what do you mean by based on? | 17:15 |
| persia | Yes, that is very inexact phrasing. Thanks for catching me. | 17:16 |
| persia | I think that there is one t.update for each t.release. | 17:16 |
| persia | And with such a mapping, I wonder if both are required. | 17:17 |
| willbarnard | I don't think that is correct | 17:17 |
| persia | Could you describe a counterexample? | 17:17 |
| willbarnard | I am wondering if a t.update is just a specialism of a t.release or not | 17:18 |
| persia | How do you mean "specialism"? | 17:19 |
| willbarnard | generalization | 17:19 |
| persia | How do you mean "generalization"? | 17:20 |
| willbarnard | the relationship may be a little more complex | 17:20 |
| persia | Do you perhaps mean that for each t.update there is a t.release, but some t.releases may not have t.updates? | 17:21 |
| willbarnard | Not exactly | 17:21 |
| willbarnard | Could we have the situation that a specific t.update can only be applied to a specific t.release, or even a specific t.release that has a specific set of t.updates applied | 17:22 |
| persia | Looking carefully, t.update seems to be a bucket for assertions, rather than being defined. As a result, I think we could make such an assertion. | 17:23 |
| persia | From your question, do you imagine that there exists a t.update between any pairwise set of t.releases for some specific t.software? | 17:24 |
| persia | Err, that should probably be "any pair of t.releases": I'm using too many words, and only ones that serve to add confusion. | 17:25 |
| willbarnard | I think all sorts of combinations may be applicable depending on the release policy of the platform | 17:25 |
| persia | Such as? | 17:25 |
| willbarnard | there may be platforms that only update replacing the entire t.software | 17:26 |
| willbarnard | in other cases there may be a corresponding t.release that is identical to applying a t.update to an earlier t.release | 17:28 |
| persia | Yes, but both in the replace nothing with something and the replace something with something situations, one needs to be prepared for the initial nothing or something in a defined way. | 17:28 |
| persia | If a t.update represents a delta between two t.releases, that is necessarily correct. If a t.update is something else, then if cannot be true. | 17:29 |
| willbarnard | I am not sure we can generalize about the way t.updates and packaged and are applied | 17:30 |
| persia | In that case, we should not have a t.update definition. | 17:31 |
| persia | I think we still need a defintion for the thing we create that is applied to production to cause it to receive new changes. | 17:32 |
| persia | Maybe that isn't "update", if the orthography gets in the way of a clean meaning. | 17:32 |
| willbarnard | ok, lets work first on a t.release definition and see if we then need an additional t.update, or we can make it general enough to cover both | 17:33 |
| persia | If we string-replace t.update with t.release, does that make more sense to you? | 17:33 |
| willbarnard | Some things there are not applicable to t.release and some things are missing | 17:34 |
| persia | What isn't applicable? | 17:34 |
| willbarnard | well the rollback, we can put some words around that one | 17:36 |
| willbarnard | I think we can use it as a starting point | 17:36 |
| willbarnard | similarly the partial release only applies for updates, but we can probably word it to cover that case | 17:37 |
| persia | Do you assert that if there are two releases, it is not required to switch between them in an arbitrary direction? | 17:38 |
| willbarnard | no I don't | 17:38 |
| persia | Then I do not understand how rollback is not applicable | 17:38 |
| willbarnard | but there are certainly platforms that do not support rollback | 17:39 |
| willbarnard | well in the case of initial release it doesn't make any sense | 17:39 |
| persia | Why not? Rollback is removal | 17:39 |
| willbarnard | Anyway, lets use this as the starting point | 17:40 |
| persia | The text replacement of "t.update" with "t.release"? | 17:41 |
| willbarnard | yes, and add the extra text we need in this section then review how that looks | 17:42 |
| persia | OK. Now let's step back to t.change. | 17:42 |
| persia | Previously we discussed how t.change could be mutable or immutable. If we choose immutable, we need a new name for the mutable thing under review. Did you want immutable? | 17:43 |
| *** willbarnard has quit IRC | 17:49 | |
| * persia decides that the departure of one's counterparty is a good time to take a short break | 17:50 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!