| *** willbarnard has joined #trustable | 07:11 | |
| willbarnard | We could add a new t.changeset definition which is mutable, but I am not sure we gain much. Currently we consider the review/merge entity as a series of immutable t.changes which is in effect a mutable type. | 07:20 |
|---|---|---|
| persia | What is the term we use for a review/merge entity? | 11:31 |
| paulsherwood | willbarnard: ^^ | 11:45 |
| willbarnard | we haven't defined a term as such | 12:27 |
| paulsherwood | let's do that | 12:27 |
| paulsherwood | persia: what do openstack call it/ | 12:27 |
| persia | "change" | 12:28 |
| willbarnard | they call it a Change | 12:28 |
| persia | I'm fine with t.changeset being that thing. | 12:28 |
| persia | Key is actually having semantics for everything that matters. | 12:28 |
| willbarnard | I agree with that | 12:28 |
| paulsherwood | ok here is there a need for t.changeset, distinct from t.change? | 12:29 |
| persia | So, if we have a t.changeset, which is composed of a set of t.changes, and during the review process, it is rejected, I think we need to be able to replace the set of t.changes in the t.changeset, while keeping some unique identifier for the t.changeset, so that we can see the history of review. | 12:29 |
| willbarnard | But as the t.change itself is an arbitrary collection of modifications, I am wondering if we really need to define another term | 12:29 |
| persia | willbarnard: The problem comes in the case where a t.change can never be merged, but we need to track the rationale for the changes that make it mergeable. | 12:30 |
| persia | The submitter of the final t.change that is merged may not be responsible for having decided to do something in a partciular manner, if that was required in order for the t.changeset to be merged. | 12:30 |
| willbarnard | do you mean t.change or t.changeset | 12:30 |
| persia | both? | 12:30 |
| persia | I mean t.change as the immutable component of history and t.changeset as the review/merge entity. | 12:31 |
| willbarnard | there are some other clashes in the terminology that open stack use | 12:31 |
| willbarnard | they refer to submission of a change to mean merge of a set of revisions | 12:31 |
| persia | Sadly, they run the conferences about CI/CD :) But for now, let's concentrate on having a consistent vocabulary, rather than worrying about what words others use. | 12:32 |
| willbarnard | whereas we use the same term to mean push of a revision | 12:32 |
| persia | What? I strongly disagree with the statement that openstack means "merge" with "submission of a change". "Submission of a change" in openstack only means pushing a branch to the SCM. | 12:32 |
| willbarnard | well if we are going to move towards the notedb standard, it might be wise to move to their terminology | 12:33 |
| persia | But I'm getting distracted :) | 12:33 |
| willbarnard | https://gerrit-documentation.storage.googleapis.com/Documentation/2.15.2/intro-user.html#submit | 12:33 |
| persia | I don't think OpenStack is a good example of NoteDB use. It is one example of gerrit use, but with a forked gerrit: probably better to harvest from one of the Linux Foundation, Google, or Mediawiki projects. | 12:34 |
| willbarnard | in the gerrit docs that is the meaning they define at least | 12:34 |
| willbarnard | perhaps the different implementations do not use a common vocabulary | 12:34 |
| persia | Yes. Gerrit defines "submit a change" as causing to be merged by the gerrit internal merger. | 12:34 |
| persia | Yes. Almost nobody uses consistent vocabulary in this space. | 12:35 |
| persia | Hence me being happy with t.change as immutable and t.changeset as tracking the review history. | 12:35 |
| persia | Years ago, I would have used t.candidate for the review history, and t.patch for the immutable item. | 12:35 |
| willbarnard | I am still not convinced of the need for t.changeset, the head t.change can serve that purpose | 12:36 |
| persia | If t.change is immutable, and the review process requires modification to be accepted, and a new (immutable) t.change is submitted with the modification, against which unique identifier are the review comments tracked? | 12:37 |
| persia | (remember, most code is going to be unmergeable the first time, unless developers replicate the entire validation and review stack in their heads, which doesn't help velocity) | 12:38 |
| willbarnard | in the gitect implementation they are saved at each commit, then the final commit is used on merge | 12:38 |
| persia | Please express that using t.change. | 12:38 |
| willbarnard | every t.change that is submitted triggers the Gate and results in the production and storage of t.evidence | 12:39 |
| persia | OK. Now, if a t.change produces t.evidence indicating it is unacceptable, and another t.change is submitted that addresses the issue, what tracks the linkage between the two t.change items? | 12:40 |
| willbarnard | the change-review-evidence holds a list of SHAs representing the t.changes in the merge/review entity | 12:41 |
| persia | That you have to express that using nouns not prefaced with 't' is my strongest argument for t.changeset | 12:42 |
| persia | So: t.changeset holds identifiers for all t.changes that have been considered for merge | 12:43 |
| persia | Or considered for a single merge operation, perhaps. | 12:43 |
| willbarnard | There are certainly some advantages to following the gerrit approach of defined the changsets with a footer, but for that to work well you probably need a local githook | 12:43 |
| * Kinnison finds that approach to be horrific because it involves the server potentially changing the commits upon submission | 12:44 | |
| willbarnard | well we have left the mechanism for defining the changset up to the policy, in the gitlab case in comes down to branching strategy | 12:44 |
| willbarnard | which server? | 12:45 |
| persia | Gerrit has a truly unfortunate implementation of tracking UUIDs for t.changeset | 12:46 |
| persia | Specifically, when one submits a branch to the magic "make me a uniquely named feature branch" API, gerrit mangles the commits to insert additional information. | 12:47 |
| persia | One *can* do that on client side, which a better implementation would do. | 12:47 |
| paulsherwood | let's not **accidentally** go the gerrit route... we should only return to that tunnel with our best spells | 12:47 |
| persia | The problem with gerrit's implementation is that the developer never has the same commits as the server, and needs to pull the mangled commits from the server to stay in sync. | 12:48 |
| persia | paulsherwood: Yes :) | 12:48 |
| persia | Mind you, I think the git footer happens to be an excellent place to put a UUID for t.changeset, so as to track it consistently over a potentially large number of t.changes, but that should be under the control of the developer. | 12:49 |
| willbarnard | it could also easily be added in a note | 12:50 |
| persia | I don't think so. The data model between notes and commits is a many-to-one relationship. This digs into implementation details, but I feel very strongly that each t.change only has a single t.changeset identifier. | 12:51 |
| willbarnard | not really, for any notes ref there is a one-to-one relationship with the commit | 12:52 |
| persia | And for any commit ref, there is a many-to-one relationship with potential notes refs | 12:52 |
| persia | Notes have a commit ref, but each commit ref may be used by multiple notes. | 12:52 |
| persia | Anyway, let's step back from implementation details. Do we agree for the need for both t.change and t.changeset? | 12:53 |
| willbarnard | so if we has a notes/changesetid ref wouldn't that have a one-to-one relationship with the commit | 12:53 |
| persia | No. One t.changeset has multiple t.changes, representing revisions of the t.change that will be merged. | 12:54 |
| persia | This is the inverse relationship to commits and notes. | 12:54 |
| willbarnard | if you mean there is redundancy that is true, but equally true if using the footer | 12:55 |
| willbarnard | I am almost convinced of the value of adding the extra definition for t.changeset | 12:56 |
| persia | Could you restate that? I don't mean anything about redundancy, but I think I don't understand your statement. | 12:56 |
| willbarnard | each commit only has one note on the specified ref so I am unsure why you think that represents a many-to-one relationship | 12:58 |
| persia | I'm confused. I thought `git notes list` output a list of the set of all notes that annotate a specific commit. This conflicts with my understanding of your statement. | 13:00 |
| persia | Err, rather `git notes list SHA` | 13:00 |
| willbarnard | I just double checked this. If you omit the SHA it gives a list of notes for all SHAs. If you include the SHA it gives the single note associated with the SHA | 13:09 |
| willbarnard | You can of course append notes but it is still considered a single note | 13:11 |
| persia | What happens when you add two notes to a single commit? | 13:11 |
| willbarnard | You can not add a second note, it will give an error message | 13:12 |
| willbarnard | You can append or replace | 13:12 |
| persia | This is a case of the porcelain and the plumbing providing different feature sets :/ | 13:13 |
| willbarnard | that is possible | 13:13 |
| persia | My experimentation with the commonly-available `git notes` implementation mirrors yours, which surprises me given the nature of the underlying representation. | 13:13 |
| persia | So yeah, as long as folk are using this git-notes, I agree that there is no useful distinction in the data model between notes and footer. | 13:13 |
| persia | Anyway, back to t.changeset | 13:14 |
| willbarnard | I think that notesdb is probably doing append, which is why they give the byte length of the payload, but I need to read more to be sure | 13:15 |
| persia | Let's not be distracted by implementations until we have a vocabulary. Most of the systems I've used for this in the past ended up being annoying because the implementation either conflated essentially different concepts or differentiated essentially similar things in ways that made it hard to explain to new contributors. | 13:16 |
| willbarnard | so if we were to add a t.changeset, what are the essential properties to define? | 13:17 |
| persia | To my mind, a t.changeset contains a list of t.changes that represent revisions to the goal. I'm not sure we need anything else, as t.evidence probably properly accrues to the individual t.changes, and merge decisions would be taken based on the t.evidence associated with the most recent t.change in t.changeset | 13:19 |
| persia | Also, as we discuss it more, I think I don't like the orthography very much. My naive interpretation of "changeset" is a set of changes that are to be merged together, rather than a set of changes representing one of the changes to be merged. | 13:20 |
| willbarnard | we should say an *ordered* list of t.changes | 13:29 |
| persia | Excellent point. It is essential to know the sequence of the t.changes so that one can properly interpret how the t.evidence led to selection of the t.change that landed. | 13:30 |
| willbarnard | the definitions have nothing about branches, merges, etc. so I am not sure we can add too much more to the definitions | 13:30 |
| * paulsherwood looks forward to the merge requests distilling this conversation | 13:33 | |
| persia | I think the lack of branch mention is intentional and good. Whether there are branches, or different servers, or just patches ends up being variable over workflow. | 13:35 |
| persia | And I don't think it matters in terms of whether the workflow can be trustable. | 13:35 |
| persia | paulsherwood: Don't get too excited. As of now, we have two things: a) we're considering a string replacement of "t.update" to "t.release", and b) we may be adding a "t.changeset" (but we're not really done with (b) yet) | 13:36 |
| * persia rereads the definitions to have a stronger opinion about mention of merge | 13:37 | |
| * paulsherwood is happy that at least we are logging this conversation | 13:37 | |
| willbarnard | persia: there is one other issue that informed our decision to keep the t.changes definition less precise. While we might advise that Git is used to to store all t.changes, in practice organizations might use other tools, especially for tracking requirements for example. In those cases, the distinction between changes and changsets may not be applicable. | 13:37 |
| persia | If we want that, then we should give up on t.change being immutable, in which case we don't need t.changeset. | 13:38 |
| persia | And the history of review and revision that goes into t.change may be represented by a series of annotated git commits or something else (doesn't matter). | 13:39 |
| persia | willbarnard: It seems the Product Policy Handler deals with the merges, so they don't need extra mention. We got distracted in our discussion of Product Policy Handler, so I suggest we postpone discussion of "merge" and how it relates to t.change or t.changeset until we've gone back up the stack and dealt with the Product Policy Handler. | 13:41 |
| willbarnard | The view we took was that it is only at the policy definition stage that we have actual mapping of tools to the roles which then determines whether we are working in a branch/merge based domain | 13:41 |
| persia | Do you not want to postpone that discussion? | 13:42 |
| willbarnard | Exactly, we tried to keep things more generic and have the Policy Handler as the placeholder to implement that | 13:43 |
| persia | So, shall we retain the current definition of t.change, and discard the assertion that t.change is immutable, to support a wider range of tooling? | 13:43 |
| paulsherwood | discard immutable | 13:44 |
| paulsherwood | with some summary of this reasoning in the commit message | 13:45 |
| willbarnard | we do not actually state that it is immutable, though that was certainly the thinking as we moved to a concrete example with the tolling | 13:45 |
| paulsherwood | (maybe even a referral to the irclog) | 13:45 |
| paulsherwood | is tolling when tooling becomes expensive? | 13:45 |
| persia | paulsherwood: We got here as we were discussing something involving changes, and whether t.change should be immutable came up, ehnce the protracted discussion on how to track review history. | 13:46 |
| paulsherwood | ack | 13:46 |
| persia | Having done that, we seem to have consensus that the easier solution is declare t.change to be mutable, which allows us to return to our previous discussion where the immutability was raised as a point of confusion. | 13:47 |
| * persia hunts backscroll to remember which that was | 13:47 | |
| persia | Aha. It was about Product Policy Handler. The specific point of confusion was on whether the Product Policy Handler ran on every t.change or ran on every modification of every t.change. | 13:49 |
| willbarnard | regarding the Policy Handler, in our gitect implementation we define that as being implemented by a combination of the gitect tool and the git server (gitlab) | 13:49 |
| persia | Again, let's avoid discussing implementations until we have semantics. Any given implementation may map perfectly to the semantics, or may not, but if we consider implmentaitons in too much detail, we'll get the semantics wrong. | 13:50 |
| persia | I believe I was arguing that we should run the Product Policy Handler on every modification of t.change (including linkage of t.evidence), expecting the vast majority of runs to fail. | 13:53 |
| persia | And I had suggested this to be the sensible model, as I did not understand how we could decide when to run the Product Policy Handler with a different model. | 13:53 |
| willbarnard | if the Gate gets that far | 13:53 |
| persia | Heh, and then we get to another point of contention. | 13:54 |
| persia | I don't think the Gate should be serialised. | 13:54 |
| persia | I think that slows reporting, which slows development. | 13:54 |
| willbarnard | for example if the t.sourcecode fails during construction, we cannot do validation | 13:54 |
| persia | And we should resolve the Gate thing before we get back to Product Policy Handler. | 13:54 |
| willbarnard | btw we dropped the Product it is just Policy Handler now | 13:55 |
| persia | Not according to https://gitlab.com/trustable/workflow/blob/master/markdown/roles.md | 13:55 |
| persia | How can we know if it is safe to do validation? | 13:55 |
| willbarnard | no, but there is a MR awaiting approval with that fix | 13:55 |
| persia | That's fine. When it is approved, I'll type fewer words. | 13:55 |
| persia | (and if the point I was making yesterday is agreed, it may never be approved) | 13:56 |
| persia | So, how can we know if is safe to do validation? | 13:57 |
| willbarnard | that is the the decision of the Gate | 13:57 |
| persia | Yes. How does it decide? | 13:57 |
| willbarnard | this is the wording that I changed following Kinnison's feedback | 13:58 |
| persia | Yes, but that is only a t.change that is not yet policy compliant. It is not safe for me to base my discussion upon it, as I have no means to know if it will be approved. | 13:59 |
| willbarnard | The new test reads "Responsible for checking the result of the construction of artefacts | 13:59 |
| willbarnard | (**t.artefact**) and triggering the Orchestrator. | 13:59 |
| willbarnard | " | 13:59 |
| persia | My general experience with Kinnison's feedback is that it is excellent. It probably should be approved. I am not an approver, so my opinion doesn't matter. | 13:59 |
| persia | So, I assert that this is an invalid way to check. | 14:00 |
| persia | Validation explicity includes static analysis, which can be done without a construction phase, and which feedback is valuable to a developer regardless of whether construction can be successful. | 14:00 |
| willbarnard | Yes, that is correct | 14:01 |
| persia | Therefore, we should not delay validation based on construction. | 14:01 |
| persia | So, is there another counterexample that suggests the gate should be serialised? | 14:02 |
| willbarnard | I am not sure we are saying anywhere that it should be serialized, only that there are some dependencies | 14:03 |
| persia | The statement "if the gate gets that far" suggests serialisation. | 14:04 |
| persia | If it is not serialised, then there is no "that far" to get. | 14:04 |
| persia | If you meant something else, my apologies. Please rephrase. | 14:04 |
| willbarnard | if all the dependencies for policy compliance check are met | 14:05 |
| persia | And how do we check the dependencies for policy compliance check? | 14:05 |
| willbarnard | that is policy dependent | 14:05 |
| persia | So, if only the Product Policy Handler deals with the Policy, and we check the policy dependencies before we run the Product Policy Handler, how is it ever run? | 14:06 |
| willbarnard | OK, so we can define that the Policy Handler itself checks whether it is ready to proceed. In practice, the Policy Handling is actually distributed across several tools. | 14:09 |
| persia | That works for me. | 14:09 |
| persia | Are you then comfortable with running the Product Policy Handler on every modification to a t.change? Most of the time it fails the basic dependency, so does almost nothing. Once in a while if fails after doing more. Very rarely it succeeds. | 14:10 |
| willbarnard | Yes, I only expect it to succeed when we are ready to merge | 14:11 |
| persia | Perfect. Now that we are in agreement, how is the Product Policy Handler different from the Validator? | 14:12 |
| willbarnard | It is a completely different beast | 14:13 |
| persia | It is something than runs on every modification to a t.change, performs some tests, and supplies t.evidence. I do not see the difference. | 14:14 |
| willbarnard | the validator may execute t.tests, the policy handler does not | 14:15 |
| persia | Which part of the definition of t.test varies from what the Product Policy Handler does? | 14:16 |
| willbarnard | t.tests validate that the t.changes meet the t.requirements | 14:17 |
| persia | So the set of approvers is not part of t.requirements? | 14:17 |
| willbarnard | policy and requirements are not the same thing | 14:17 |
| persia | How do you define t.policy? | 14:18 |
| willbarnard | t.requirements define the functionality of t.software | 14:18 |
| persia | From my perspective, it is simply the set of requirements imposed by the organisatoin about how the sofdtware is developed. | 14:18 |
| willbarnard | policy defines the operation of the software development process | 14:18 |
| willbarnard | yes, that is a very important distinction | 14:19 |
| persia | Do we need to add a "functionality" statement to the t.requirments definition? It isn't there now. | 14:19 |
| willbarnard | two completely different policies can product exactly the same software to meet the same requirements | 14:19 |
| persia | I assert that a t.intent could be "the person approving a merge should not be the person who wrote the change", which would result in a t.requirement that could be validated. | 14:19 |
| persia | You still haven't defined "policy" in this context. | 14:20 |
| willbarnard | I do not believe that is a software requirement | 14:20 |
| paulsherwood | i'd like to see it defined, even so | 14:20 |
| persia | That's fine, if we're using English, but do you have an objection to it being a t.requirement? If so, which part of t.requirement is unmet? | 14:20 |
| willbarnard | We have not defined policy, I recall there are a few statements that talk about process | 14:21 |
| * persia would prefer not to have a definition of t.policy, but is unable to argue effectively against it without a strawman to use to show equivalence to another type. | 14:21 | |
| persia | So, let's define policy. | 14:21 |
| persia | And I'll argue about how it is the same as t.requirements | 14:21 |
| persia | Or let's identify which part of t.requirements is wrong, such that it automatically excludes "policy" | 14:22 |
| willbarnard | policy is about how the the software is developed not what the software does | 14:22 |
| persia | That isn't inconsitent with policy being in t.requirements | 14:22 |
| willbarnard | the end user does not care about the policy | 14:22 |
| persia | Hrm? Why not? I'm more likely to use software that has been certified to be compliant with various policies. | 14:23 |
| persia | Am I particularly odd in that regard? Does nobody else look for the labels in the back that make sure the police don't come around to ask why one is using a radio on the wrong frequencies? | 14:23 |
| persia | (as one example) | 14:23 |
| willbarnard | that is a requirement not a policy | 14:23 |
| persia | No, it's a policy. Most regulations are. If you want a narrower definition for "policy", please supply one. | 14:24 |
| willbarnard | standards are explicitly defined as a type of requirement | 14:24 |
| willbarnard | policy here is software development policy | 14:24 |
| persia | (side note: t.requirements MUST be both complete and consistent: this is provably impossible) | 14:25 |
| persia | What is "software development policy" in terms similar to what we have in the document for t.requirements? | 14:25 |
| willbarnard | the end user of thesoftware care what git branching strategy was used, he doesn't even know what git is... | 14:25 |
| persia | (and most importantly, in what way does "software development policy" differ from the current definition of t.requirements) | 14:25 |
| persia | Again, let's ignore implemnentations until we have consistent semantics. | 14:26 |
| willbarnard | policy has nothing to do with requirements | 14:27 |
| willbarnard | they are completely different things | 14:27 |
| persia | Please explain how they differ. | 14:28 |
| willbarnard | a policy might be we merge branches on thursdays, a requirement might be that the software gives an audible warning beep | 14:29 |
| persia | Those are fine examples, but if we are to refine our definition of t.requirements to exclude what you call "policy", and create a t.policy, we need to describe the structural ways in which they differ. | 14:30 |
| persia | As I do not see a difference, I am ill-placed to provide such a description. | 14:30 |
| willbarnard | I don't think the t.requirement definition needs to be changed to exclude policy, but it may well need improvements for other reasons | 14:33 |
| persia | It clearly does: my aside above indicates that the current definition cannot ever be met :) | 14:33 |
| persia | So, if t.requirement is not changed to exclude policy, are you willing to stipulate that t.requirement includes both "functional requirements" and "software development policies"? | 14:34 |
| willbarnard | No | 14:34 |
| persia | Then why doesn't t.requirement need to change to exclude policy? | 14:34 |
| willbarnard | it only includes requirements | 14:35 |
| persia | It *defines* requirements. We can't use random english words to guide this. | 14:35 |
| persia | Would it be easier if we spelled t.requirments t.14 ? | 14:35 |
| willbarnard | I am not sure why we would need to explicitly exclude things which are unrelated | 14:36 |
| persia | You assert a lack of relation. I assert identity. | 14:36 |
| persia | My assertion of identity is based on policy being associated with intent, policy being unambiguous, policy being verifiable, policy being cohesive, policy being traceable from evidence, and policy requiring tests. | 14:37 |
| persia | I disagree with the other parts of t.requirement (but we can discuss those separately). | 14:38 |
| persia | (note that my disagreement is general, and unrelated to this particular subpoint) | 14:38 |
| persia | So, what is the basis of your assertion? | 14:38 |
| * paulsherwood *really* hopes persia can achieve a gitlab account, to offer patches directly :) | 14:38 | |
| persia | paulsherwood: In some ways, I think conversations like this are more valuable than just patches, as I think the process of discussion is important. It may seem odd to have spent 2-3 hours discussing whether t.change is mutable, but I think we all have a deeper understanding of what we mean as a result. I'm not sure that would have happened with a one-line patch asserting mutability (which isn't even required, as there is no assertion of | 14:40 |
| persia | immutability). | 14:40 |
| paulsherwood | persia: i do agree with the value of the conversations | 14:45 |
| paulsherwood | so long as we retain the gist, and do patch appropriately | 14:46 |
| persia | I believe we shall | 14:46 |
| persia | So far, we only have one potential change, being "t.update" to "t.release", as a pure string change, with no semantic value. | 14:49 |
| willbarnard | I have a change for that | 14:49 |
| persia | Cool :) | 14:49 |
| persia | Any progress on the argument for t.policy? Do you want to take some time, and we can reconvene? | 14:50 |
| persia | Alternately, do you want to explore the bits of t.requirement with which I disagree, and then come back to how "software development policy" is not t.requirement? | 14:51 |
| willbarnard | I am thinking if there is a better way to explain this. I see a fundamental difference between them, one relates to the software itself and one the software development process | 14:52 |
| persia | In my mind, t.software encapsulates (either directly or by reference) all t.intent, t.requirements, t.tests, etc. This would include any policy related to the development. | 14:52 |
| persia | It may be that the policy for changing policy differs from the policy for changing, say, intent, but that is covered by inclusion by reference (and being more specific digs into implementation details). | 14:53 |
| willbarnard | I also disagree with those statements, I didn't remove them in my earlier pruning as I wanted first to understand what the rationale was to include them originally | 14:53 |
| persia | My suspicion is that someone captured a discussion about ideas without subjecting them to rigorous analysis. | 14:54 |
| persia | "true" and "correct" are very alluring concepts, as indefensible as they end up being under scrutiny. | 14:54 |
| willbarnard | Agreed | 14:55 |
| persia | I feel like the distinction between requirements for process and requirements for functionality is similar in that way. Both end up being represented by code snippets that provide an output in some range that can be consumed to trigger further action. | 14:58 |
| persia | But in some sense the same functionality can be exposed regardless of the process. | 14:58 |
| persia | This is why I asked if it would work better if we changed "t.requirements" to "t.14" : that then becomes the conflation of the two classes of requirement. | 14:59 |
| willbarnard | I don't think it is useful to conflate requirements and policy | 14:59 |
| persia | On the other hand, we can accept the conflation without the string change, which implies we accept the case that different sets of t.requirements may result in the same t.artefact | 15:00 |
| persia | I don't understand how it is useful to disambiguate them. | 15:00 |
| persia | To my mind, the main impact of disambiguation is to make the analysis of compliance more difficult and require more different pieces of software. | 15:00 |
| persia | That doesn't strike me as beneficial to either development velocity or confidence in the final result. | 15:01 |
| persia | Am I missing something? Is there a benefit I don't see? | 15:15 |
| willbarnard | Lets come back to this one, I don't see that we will resolve it today | 15:27 |
| persia | OK. | 15:31 |
| persia | Sadly, that also blocks going back to Product Policy Handler. | 15:32 |
| persia | Before that, we were discussing the role of the Gate. We revisited that briefly today, but only in terms of serialisation. | 15:34 |
| persia | I can't quite tell from backscroll: did we agree that there was no need to serialise the gate? | 15:34 |
| persia | I think we did in terms of Product Policy Handler and Validator, but I don't think we touched on the other gate functions. | 15:35 |
| persia | (side nit: we have "Policy Compliance Checker" in the gate defintion and "Product Policy Handler" in the main role list. This appears to be addressed in 9fbb7cc6f2a3afae4db2df55bbe116f2a9ea942a) | 15:37 |
| *** willbarnard has quit IRC | 16:55 | |
| *** chrispolin has quit IRC | 18:03 | |
| *** ltu has quit IRC | 18:03 | |
| *** milloni has quit IRC | 18:03 | |
| *** chrispolin has joined #trustable | 18:06 | |
| *** paulsherwood has quit IRC | 18:07 | |
| *** laurence- has joined #trustable | 18:09 | |
| *** milloni has joined #trustable | 18:11 | |
| *** traveltissues has quit IRC | 19:24 | |
| *** traveltissues has joined #trustable | 19:25 | |
| *** paulsherwood has joined #trustable | 21:03 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!