IRC logs for #trustable for Monday, 2018-06-25

*** traveltissues has joined #trustable05:27
*** willbarnard has joined #trustable07:52
*** sambishop has joined #trustable08:25
*** willbarnard has quit IRC08:46
*** willbarnard has joined #trustable08:53
*** willbarnard has quit IRC09:13
*** willbarnard has joined #trustable09:13
willbarnardpersia: 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
persiaThe definition I linked assumes a model where there may be an arbitrary number of merges prior to completion of all relevant pipelines.14:32
persiaThe contrast you mention suggests a definition of "merge" as a final action.  Am I confused?14:32
willbarnardIn our model there will be an arbitrary number of merges, within each merge pipeline there are a number of gating decisions14:35
persiaI think I have to read your definitions more in order to have this conversation.14:36
persiaEssentially "merge pipeline" is meaningless to me, which complicates any response :)14:36
persiaIt 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
willbarnardNot 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
persiaRight.  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
paulsherwoodpersia: do you see problems in what willbarnard is describing?14:41
persiaI 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
persiaAside 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
willbarnardSure that is exactly what we have said, the Validator role may be automated or manual14:43
persiaAs an example supporting the idea that my opinions are based on incorrect definitions :)14:43
willbarnardIn many cases there will be a combination of both types of validation14: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
paulsherwoodwillbarnard: i think the Reviewer role may also be automated or manual...14:50
willbarnardThat 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
paulsherwoodwhere is our current definition of review?14:54
persiaFrustratingly, starting from, I had trouble finding the repo in which the definitions live, but more frustratingly, had an error, which someone probably wants to investigate.14:54
paulsherwoodwhere did you get that link from? we moved to a long time ago14:55
willbarnardI don't recall that we have a formal definition of review14:56
paulsherwoodlet's fix that, then14:56
persiapaulsherwood: Linked from
paulsherwoodpersia: iiuc you are hinting that review can be automated?14:56
persiaIt depends on how you define "Review".14:56
willbarnardI suspect that what persia is calling review we are calling validation14:57
persiaI 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
persiawillbarnard: 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
willbarnardpossibly, could you give an example of the automated review tasks so we can be clear what we are talking about?14:59
persiaI do not understand how that provides clarity, as you are asking for tasks without providing a definition.15:01
persiaIf 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
persiaIf 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
persiaI could go on, but without a shared understanding of "review", I don't think such a list has much value.15:02
paulsherwoodpersia: i think it does have value...15:02
persiaI remember there being some document that specified what words mean, but I cannot find it in the git repos that are linked from 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
persiapaulsherwood: Why?15:02
paulsherwoodsee above15:03
persiaI'd rather start from a draft definition :)15:03
persiaYes: timing :)15:03
willbarnardin 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 review15:03
persiaBefore this conversation, my definition of review was "an action consuming a candidate and resulting in a vote about the candidate".15:03
paulsherwoodpersia: patches welcome15:04
persiaWell, 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
persiaUntil then, I shall comment about things if asked, but maybe not produce patches.15:04
willbarnardfrom 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 reviewed15:05
persiaand with those definitions, I understand the confusion about "Gate": that's clearly heavily overloaded.15:06
paulsherwoodwhat stopped your attempts?15:06
persiawillbarnard: That implies review by a human15:06
willbarnardyes, we have considered review to be a human task15:06
persiapaulsherwood: Usually a sense that I had wasted yet another day attempting to register.15:06
persiawillbarnard: Right.  IF "review" is a human task, then no review activity can be automated.15:07
persiaWhich causes us to categorise all activities that can be automated as other than "review".15:07
persiaAnd 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 attempts15:07
persiapaulsherwood: You hav e guessed wrong.15:08
persiaTo be fair, some of them were only three.  Last tuesday was 5.15:08
paulsherwoodwhat is the actual difficulty? most people appear able to register more easily15:09
persiaSometimes 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
persiaCurrently, 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
persiawillbarnard: 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
willbarnardYes, that is its role15:18
persiaI 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
persiaI agree that with that defintion of "gate", gating and merging are unrelated.15:19
persiaI'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
willbarnardWe have tried to separate the roles. In practice many tools actually perform more than one role.15:19
persiaI feel it is important to either explicitly declare such conflation or to avoid the conflation.15:20
willbarnardI would certainly agree with that15:21
persiaImplicit 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
persiaFor 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
persiaSome 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
willbarnardpersia: 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
persiaNo, actually.  I think that would overreach.15:33
persiaIn my opinion, the definition of the state machine is properly a policy determination to be made by the implementing organisation.15:33
persiaI 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
willbarnardthat is what the policy handler does in our model15:36
persiaIn terms of definitions, my first opinion from looking at them is that there are too many.15:36
willbarnardthe t.definitions?15:36
persiaWhich is what the policy handler does?15:36
persiaYes.  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
willbarnardsupports a range of different policies that are organization defined15:37
willbarnardI agree, I made a first pass at that so have removed quite a number already15:38
persiaSo, reading that definition, I do not understand why "Product Policy Handler" is defined.15:38
persiaHow does it differ from "Validator"?15:38
willbarnardvalidator performs the validations15:38
willbarnarde.g. run tests, lint, etc.15:39
persiaSo, 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
persiaUnless "Product Poilicy Handler" is always human (whereas I think it is a trivially automatable role)15:40
willbarnardthe policy handler looks at the conditions required by the project policy15:41
persiaHow is "looks at" defined?15:41
willbarnarde.g. what type of approvals are needed, what tests results are required, etc.15:41
willbarnardtakes the policy configuration and policy data as inputs and produces a binary result15:42
persiaI presume that is a definition of "conditions".15:42
persiaHow does it produce the binary result?  Does it perform a test?15:42
willbarnardnot a test of the but a test of the policy conditions, yes15:43
persiat.test isn't domain-restricted.15:44
willbarnardI think should be otherwise every if statement in the code would be a t.test which is clearly nonsense15:45
persiaSo, either the product policy handler and the validator are the same *OR* t.test needs to be defined more closely.15:45
persiaHow do you get there?15:46
willbarnardI would certainly like to see t.test more tightly defined15:46
persiat.test is mapped to t.requirement, executes in t.ernvironment, and produces t.evidence.15:46
persiaIt is possible to have conditional statements in code that don't meet that definition.15:46
willbarnardThe t.test definition is missing the actual definition of what a test is15:48
persiaTightening 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
persiaMy read of the current definition of t.test is that a test can be *anything* that has the right inputs and outputs.15:49
persiaSo 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
persiaA 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
willbarnardwell I think we should explicitly say that it exercises t.software15:51
persiaWhy?  That forces the definition of "Product Policy Handler", and also requires some equivalience of t.test for policy compliance.15:51
willbarnardnot sure I follow15:52
persiaSo, 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
persiaIf 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
persiaCurrently there is no noun for the check performed by the "Product Policy Handler".15:54
persiaThis represents semantic inconsistency, which can be solved either way.15:54
willbarnardNot at all, the policy compliance handler is implementing the policy compliance check15:54
persiaWhich is defined as which term on ?15:55
willbarnardone of the many things that are not defined on that page15:57
persiaIn that case, I think we agree.  The "Product Policy Handler" has no noun, which is a semantic inconsistency.15:57
persiaI 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
persiaMy 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
willbarnardWe 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 finished16:01
persiaPlease explain both of these points.  I do not agree with either at face value.16:01
willbarnardThe policy may depend upon the results of all the validations, in addition to approvals which may only be performed after validation16:03
persiaI 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
persiaIn other context, I typically see that role being executed on every modification to a t.change16:05
willbarnardKinnison: I have made some changed in MR!28 which hopefully covers the points you raised last week16:05
persiaConversely, 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
willbarnardyes, on every t.change16:06
* persia reviews the t.change definition again16:07
persiaNo, not every t.change, every modification of a t.change16:07
willbarnardthere is no such thing as a modification of a t.change16:07
persiaUm, then I'm really confused.16:07
willbarnardwe model all inputs as a series of t.changes16:08
persiaFor me, a change is a submitted suggestion of something that the submitter expects to be changed.16:08
willbarnardthink of t.change as a single commit16:08
persiaAs it moves through process, the submitter may change their mind, and change the t.change.16:08
persiaIf that isn't permitted, I cannot understand why any submitter would ever submit a change.16:08
persiaYes.  t.change is a commit.16:08
willbarnardevery time you commit you create a t.change16:08
KinnisonI imagine it depends on whether you think of a t.change as something which has been proposed, or something which has been accepted16:09
persiaGiven that it is input to t.test, I consider it something that is proposed.16:09
willbarnardso a set of t.changes produced the currect status16:09
Kinnisonif you think of t.change as immutable, a proposed t.change still can't change, but it could be replaced with a different t.change16:09
KinnisonWhich, at a superficial level, you could think of as 'changing the t.change proposed'16:09
persiaAh.  If we want immutable t.change, we should include that in a definiton.16:09
KinnisonAs I describe it just there ^^ is basically gerrit16:10
persiaI 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
KinnisonFor 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 time16:10
willbarnardthe gerrit/notedb definition is a little different, they define a Change and an aggregation of an aggregation of commits16:11
* Kinnison has no idea what the appropriate wording would be16:11
persiaYes.  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
persiawillbarnard: 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
persiaKey is that there are two things here.  One is immutable, and the other is mutable.16:12
persiaIf 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
willbarnardwell I think that comes down to policy16:15
persiaHow do you mean?16:15
willbarnardif you want to squash the commits on merge16:15
persiaRather, 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
persiasquash/non-squash is irrelevant.16:16
* Kinnison thinks willbarnard and persia are talking slightly across from one another.16:17
Kinnisonwillbarnard: persia is interpreting 't.change' as a merge *request*16:17
* persia knows this to be true16:17
willbarnardKinnison: my question is whether it is clearer to you with the changes I have made16:17
Kinnisonwillbarnard: If that's not meant to be the case, then such a thing needs a t.whatever16:17
KinnisonI've not read the MR yet, been busy with other things16:17
persiaKinnison: I'm trying very hard to interpret t.change precisely as described at : I only consider a merge-request to be an example of that.16:17
Kinnisonthen got distracted with this conversation16:17
willbarnardno rush, just letting you know there is an update16:17
Kinnisonpersia: Aaah I interpret the t.change from that document as a commit16:18
willbarnardyes, the t.change definition is basically a single commit16:18
persiaKinnison: I think the document doesn't clearly indicate whether either of us is correct.16:18
willbarnardwe will run the gate for each t.change submission16:18
willbarnardthe policy will fail until the set of changes is ready for merge16:19
Kinnisonpersia: Given that this discussion could happen at all, I believe you are correct - there is ambiguity16:19
persiawillbarnard: I consider those statements true for either mutable or immutable t.change.16:19
willbarnardThe is certainly room for improvement in the wording16:19
persiaI'm not convinced there is a problem with the wording.16:19
persiaI 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 vocabularies16:20
persiaOr, 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
willbarnardin 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 state16:21
persiaWhat?  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
willbarnardat the time the the policy passes we only care about the result of the set of changes not the intermediate states16:22
persiaThat runs counter to the common arguments I hear about having a true history.  I support the idea of fictional history.16:22
persiaI'm not sure what value we have if all history is fictional though.16:22
willbarnardagain that is a policy decision, I don't think we should mandate a specific policy16:23
willbarnardthere is certainly a strong case for some careful tidy up16:23
persiaAlthough 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
persiaIf there is not a standard of evidence that would cause it to be trusted, how can the result be trustable?16:24
willbarnardthe view we have taken is that the evidence generated on the commit that is merged is the one we care about16:25
persiamerged to which tree?16:26
willbarnardalthough branching strategy is a policy decision16:26
persiaWhich 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
willbarnardyou will notice there is nothing yet in the t.defintions for t.release, although strangely we do have a t.update...16:27
persiaI believe that is correct.  I believe "release" has no meaning in a software development context.16:29
persiaThe importnat time is when the software is changed in production.  Someone publishing a website doesn't affect anything.16:29
willbarnardabsolutely, that would be my definition of release16:30
persiaWhich is your definition of release?16:31
willbarnardthe build that is released to production16:31
persiaFor which production instance?16:31
persiaI assert that for successful software there are so many production instances that they cannot usefully be tracked by the development group.16:32
persiaWhereas it does become possible to track potential updates, which may be applied by others at the time of their convenience.16:32
willbarnardwell they could be flashed in the factory, updated in the field, it depends on the type of software16:33
willbarnardfor the type of software that requires the trustable approach there are probably some long running compliance tests that need to be executed on that build16:34
persiaI 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
persiaSadly, this means that I expect nearly all software subject to compliance review will have demonstrable insecurities at the time of update.16:35
Kinnisonwillbarnard: !28 looks like it addresses the direct concerns I had last week16:36
persiaAnyway, 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
persiaOr, more formally: t.release * is a t.artefact * is installed in t.environment * is expected to be used for non-validation tasks16:38
willbarnardyes, that is my view16:38
persiaOh, we probably also want * a t.release must be uniquely identifiable16:39
willbarnardyes, we will need to few specifics for it16:39
persiaNow, just to confirm we really need this word: what does it give us that we do not get from t.artefact16:39
persiaAlternately put, would it make as much sense to implement t.release by replacing every string of "t.artefact" with "t.release"?16:41
willbarnardis it a t.artefact or a
persiaI think it is t.artefact, because t.artefact is defined as having been constructed (so suitable for use), whereas appears to be unconstructed.16:42
willbarnardthe difference is that there are likely to be different policy criteria that apply to a t.release16:43
persiaBut I admit to not understanding why either or t.sourcecode exist with that interpretation of t.software16:43
willbarnardI dont think that was the original intention of the definition16:43 is a little different16:44
persiaAre 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
willbarnardt.sourcecode (I would prefer t.source) is meant to be the unconstructed t.change16:45
persiaYes, but I need a *collection* of t.changes to have something from which I can construct an artefact.16:45
persiaI can't use a single t.change: it is only meaningful in the context of the history of all changes.16:46
willbarnardthat is true, unless you write the whole system in one commit16:46
willbarnardMy only question about your statement is whether we should use rather than t.artefact16:47
persiaHeh, right, but then when I update it, my next "release" needs to be a t.artefact from, as I can only do that once :)16:47
persiaAs 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
willbarnarddoesnt that depend on whether we have a partial update16:48
persiaI do not read the definition of in a way that permits it to be so installed in t.environment.16:48
willbarnarddo we need the definition?16:48
persiaNote 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.software16:48
persiaI think so, as we need a source input from which to create t.artefact16:49
willbarnardI think the source input is t.sourecode16:49
persiaI also don't see any useful difference between and t.sourcecode16:49
persiaI like the definition of better than the definition of t.sourcecode.  I suggest that t.sourcecode be removed from the vocabulary.  We can rename to t.source or t.sourcecode as a follow-up operation.16:50
willbarnardthen there is a case for removing but I would like to hear the view of the original author of that16:50
persiaIs the original author in-channel?16:51
persiaWait, hrm?  What case for removing
persiaI agree with renaming it.  I cannot agree with removing it.  Nothing else serves as a container for the set of t.changes.16:51
willbarnardIt is the container for t.changes and the link to t.requirements16:53
willbarnardif we use t.artefact then the t.release could be a t.artefact or a collection of t.artefacts16:55
persiaRight, so I think we need  I'm open to renaming it.  You wrote "then there is a case for removing".  I'd like to read that case.16:55
persiaTo meet the requirement that a t.update be atomically applicable, I think we need t.release to represent such a collection of t.artefacts16:56
persiaUnless we only have t.update and don't bother with t.release at all.16:56
willbarnardI am wondering what the original intended meaning of was16:56
willbarnardor we have t.release and don't bother with t.update at all16:57
persiaI think was intended as a noun to represent a collection of t.changes and link to t.intents, t.requirements, t.metrics, and t.evidence16:57
persiaPersonally, I'd prefer if 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
persiaAnyway, regardess of how we define, let's look more closely at whether we need t.release.17:00
willbarnardshould that be is a collection or has a collection?17:00
persiaFor 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
persiaIn 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
willbarnardwell the data relationship is different, but we can look later how to improve that wording17:02
persiaCould you explain how you think the data relationship is different?17:02
willbarnardI would be happy to define t.release as an aggregation of t.artefacts17:04
willbarnardwe just need to define those specific conditions that define a specific aggregation as forming a t.release17:05
persiaSo, 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
willbarnardit depends how we want to define it17:12
willbarnardbut the restrictions we apply to aggregation of t.artefacts that form a t.release should also apply to those that form a t.update17:14
willbarnardthere may be additional conditions that we want to apply to t.update that are not applicable to t.release17:14
persiaYes.  What I'm wondering is whether t.update covers enough that we don't need t.release.17:14
persiaMy assertion is that if we do not have any specific differentiators, we should not have a new word.17:15
willbarnardI don't believe the current definition does17:15
persiaWould you agree that t.release is a collection of t.artefacts and a t.update is based on t.release?17:15
willbarnardwhat do you mean by based on?17:15
persiaYes, that is very inexact phrasing.  Thanks for catching me.17:16
persiaI think that there is one t.update for each t.release.17:16
persiaAnd with such a mapping, I wonder if both are required.17:17
willbarnardI don't think that is correct17:17
persiaCould you describe a counterexample?17:17
willbarnardI am wondering if a t.update is just a specialism of a t.release or not17:18
persiaHow do you mean "specialism"?17:19
persiaHow do you mean "generalization"?17:20
willbarnardthe relationship may be a little more complex17:20
persiaDo you perhaps mean that for each t.update there is a t.release, but some t.releases may not have t.updates?17:21
willbarnardNot exactly17:21
willbarnardCould 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 applied17:22
persiaLooking 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
persiaFrom your question, do you imagine that there exists a t.update between any pairwise set of t.releases for some specific
persiaErr, 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
willbarnardI think all sorts of combinations may be applicable depending on the release policy of the platform17:25
persiaSuch as?17:25
willbarnardthere may be platforms that only update replacing the entire t.software17:26
willbarnardin other cases there may be a corresponding t.release that is identical to applying a t.update to an earlier t.release17:28
persiaYes, 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
persiaIf 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
willbarnardI am not sure we can generalize about the way t.updates and packaged and are applied17:30
persiaIn that case, we should not have a t.update definition.17:31
persiaI 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
persiaMaybe that isn't "update", if the orthography gets in the way of a clean meaning.17:32
willbarnardok, 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 both17:33
persiaIf we string-replace t.update with t.release, does that make more sense to you?17:33
willbarnardSome things there are not applicable to t.release and some things are missing17:34
persiaWhat isn't applicable?17:34
willbarnardwell the rollback, we can put some words around that one17:36
willbarnardI think we can use it as a starting point17:36
willbarnardsimilarly the partial release only applies for updates, but we can probably word it to cover that case17:37
persiaDo you assert that if there are two releases, it is not required to switch between them in an arbitrary direction?17:38
willbarnardno I don't17:38
persiaThen I do not understand how rollback is not applicable17:38
willbarnardbut there are certainly platforms that do not support rollback17:39
willbarnardwell in the case of initial release it doesn't make any sense17:39
persiaWhy not?  Rollback is removal17:39
willbarnardAnyway, lets use this as the starting point17:40
persiaThe text replacement of "t.update" with "t.release"?17:41
willbarnardyes, and add the extra text we need in this section then review how that looks17:42
persiaOK.  Now let's step back to t.change.17:42
persiaPreviously 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 IRC17:49
* persia decides that the departure of one's counterparty is a good time to take a short break17:50

Generated by 2.15.3 by Marius Gedminas - find it at!