| *** toscalix has joined #trustable | 09:04 | |
| *** locallycompact has quit IRC | 10:08 | |
| *** locallycompact has joined #trustable | 10:09 | |
| *** persia has quit IRC | 12:46 | |
| *** persia has joined #trustable | 12:47 | |
| *** chrispolin has quit IRC | 13:22 | |
| *** ltu has quit IRC | 13:22 | |
| *** chrispolin has joined #trustable | 13:24 | |
| *** Guest1639 has quit IRC | 13:31 | |
| *** tiago has joined #trustable | 13:31 | |
| *** laurenceurhegyi has joined #trustable | 13:36 | |
| *** locallycompact has quit IRC | 14:24 | |
| *** locallycompact has joined #trustable | 14:24 | |
| *** bapophis has joined #trustable | 15:15 | |
| paulsherwood | bapophis: are you ok with my answers at https://gitlab.com/trustable/workflow/merge_requests/6 ? | 15:15 |
|---|---|---|
| * paulsherwood is planning to do a new MR, will take into account any feedback from bapophis | 15:17 | |
| bapophis | i'll need some time to read these and i'd like to finish my current, what's your cut-off time | 15:18 |
| paulsherwood | no rush | 15:18 |
| paulsherwood | i'll probably work on revised patch tmrw or fri | 15:19 |
| * persia is somewhat disappointed to get a "you don't have permission" message from that URL. | 15:22 | |
| paulsherwood | interesting | 15:24 |
| paulsherwood | persia: pls try now? | 15:24 |
| persia | paulsherwood: Works now. | 15:25 |
| paulsherwood | persia: ack, thanks. sorry for the mixup | 15:26 |
| persia | For clarity, I don't have specific feedback on the review, but I do have strong opinions about transparency of development for #trustable :) | 15:26 |
| * persia is well behind, and hopes to find time to review the current state of things next month: based on a quick glance a couple weeks ago, lots of exciting epistemological work has been done | 15:28 | |
| *** laurenceurhegyi is now known as ltu | 15:29 | |
| paulsherwood | s/done/started/ | 15:36 |
| paulsherwood | yup to transparency, that was simply a mistake | 15:36 |
| *** locallycompact has quit IRC | 16:45 | |
| *** toscalix has quit IRC | 17:45 | |
| bapophis | paulsherwood, i'm happy with those answers now but added some thoughts | 20:06 |
| persia | bapophis: Briefly, my feeling is that the specifics of "review" are a local policy decision, and independent of the trustable framework. It might make sense to have a test that runs against a policy doc that can claim "this policy is insufficient" or "this policy is sufficient", but I think the right way to determine if "review" is met is whether the criteria specified by policy are met. | 20:09 |
| persia | For at least one automated gatekeeper, it is possible to specify policy such that different criteria are required for each of different repos and different files within a repo, where that policy may include running different tests and/or different roles of human review being needed. | 20:10 |
| bapophis | i think i added something to that effect at https://gitlab.com/trustable/workflow/merge_requests/6#note_60031153 | 20:10 |
| persia | That is precisely the thing to which I was responding :) | 20:11 |
| persia | The main point of my statement was to introduce t.policy, which governs the review process. | 20:12 |
| bapophis | ok, i agree with you | 20:12 |
| bapophis | i was also not aware of that, i've only just started looking at this project and haven't had much time to poke it | 20:12 |
| persia | I don't think t.policy is in the repo anywhere: it's just a leftover from my pre-formalised thought on the subject. | 20:13 |
| bapophis | it seems like there need to be policy or high-level frameworks though | 20:14 |
| persia | Also, your point about regressions is one that I have yet to untangle: dealing with a requirements change that causes behaviour to differ in a way incompatible with a previous requirements change is something for which I've spent a bit of time being frustrated about the limitations of ordered history and aging of unmerged members of a merkle tree. | 20:14 |
| persia | Yes. Any review pipeline must have a policy. In gerrit, this is configurable (by adding the right bits to the right git repos) and can be queried as is:submittable | 20:16 |
| persia | But it would be nice to have a more generic system, ideally with consensus by all git users about notation and storage | 20:17 |
| persia | (sadly, git-configured git servers like gerrit and gitano all seem to have different custom ways to configure permissions, etc.) | 20:17 |
| bapophis | i can imagine a scenario where a change is accepted and causes requirement satisfaction but the effect is that other requirements are not satisfiable. that would mean there is a net negative change in requirements state but being able to determine that is (i think) non-trivial | 20:20 |
| persia | I think there are two separable factors. | 20:21 |
| persia | Firstly, there is a state condition of whether a requirement has been implemented. | 20:21 |
| persia | Changes to unimplemented requirements are unimportant. Changes to implemented requirements can cause regressoin. | 20:21 |
| persia | Where there is a requirement that is implemented, any new requirement must either be consistent with the prior requirement, or the requirements change and implementation change must be merged in lock-step. | 20:22 |
| persia | So, secondly, requirements must test if they are met, and a requirements change must both remove the now-outdated requirement and introduce a new requirement. | 20:23 |
| persia | This is all fine if we can assume that each requirement is atomic, but it all breaks down if we assume that a requirement is an artifact generated as a result of a change history. | 20:23 |
| persia | Because that implies that it is possible for a requirements change that modifies an implemented requirement (and so must be merged in lock-step) to be in a merge-conflict state. | 20:24 |
| persia | One potential implementation is to have any code change Depends-On: the relevant requirements change, and have the requirements change include the necessary test changes to describe the desired state of the project after the change. | 20:25 |
| persia | But this means that the requirments change may need to be re-reviewed by stakeholders to be implemented, if it reaches a state of merge conflict before implementation is complete. | 20:26 |
| persia | Anyway, it's messy. My thoughts here aren't complete. | 20:26 |
| bapophis | i think that has the potential to end up jamming the process | 20:28 |
| persia | Yep. That's the hard part. | 20:28 |
| persia | The other possibility is to have a requirements tracker of some sort that marks requirements as met once impleentations have merged. | 20:28 |
| bapophis | i think this would be more clear with an abstract model | 20:29 |
| persia | gating then depends on a) compliance with all previously implemented requirements and b) compliance with any requirement implemnented by the new change. | 20:29 |
| persia | Unfortunately, I've been unable to determine how to deal with a change to an implemented requirement with such a model. | 20:29 |
| persia | (for the second possibility, I'm assuming that requirements changes are merged upon approval, regardless of implementation status) | 20:31 |
| persia | How do you mean more abstract? | 20:31 |
| persia | While an implementation as a merkle tree is handy, I don't think it's important to the problem. | 20:32 |
| persia | But I think we lose valuable information if we aren't considering artifacts generated by streams of changes, and logical tests that can be applied to those artifacts (or the results of computational processing of some artifacts against other artifacts) in order to gate from "proposed change" to "change that is part of a change stream that we declare as true" | 20:33 |
| persia | calling some artifacts "requiremetns" and others "code" is just a convention to deal with the fact that people like to use semantic tags to which they have previously mapped meaning to discuss the issue. | 20:34 |
| bapophis | well that's part of my point, language can be messy on these topics, i'd find it useful to make an object representation | 20:35 |
| persia | Ah, that makes sense. | 20:35 |
| * persia has perhaps been thinking about this class of problems for too many decades, and so has some built-in assumptions as a result | 20:36 | |
| bapophis | perhaps. but i've been thinking about this class of problems for about 15min so we may have to meet in the middle | 20:40 |
| persia | Heh, yep. If you do put together an object model, I'd be delighted to see it. | 20:41 |
| paulsherwood | interesting discussion... anyone care to offer a patch defining t.policy? | 21:43 |
| * paulsherwood would be very interested in a PoC abstract model, and/or a solver for the the schema logic that we are (on the way to) describing | 21:44 | |
| persia | paulsherwood: You shouldn't wait for me to dig through the work done to date, but loosely, policy is just a declaration of the conditions to be met before a change can pass gate. Most implementations seem to involve specifying certain combinations of "votes" against "labels", including a set of labels that must have votes, and minimum values for the votes (both in magnitude of individual votes and number of votes). An example would be "Code-Review: | 22:07 |
| persia | requires at lesat one +1 and at least one +2 and no -2s; Verify: requires at least one +1". A more complex policy for a specific repo might include things like voting against compliance, risk, or authorisation labels. | 22:07 |
| persia | I haven't thought about abstract implementations that much, but I suppose the permissions model that groups identities into roles and permits roles ranges of vote values against labels is also part of policy. | 22:08 |
| persia | If nobody else gets to it first, I might submit a patch in the future, but I hope the idea isn't stagnant that long :) | 22:08 |
| persia | (to be fair, part of that is that I find the policy of restricting candidate change modification to change owners to be sufficiently anticollaborative that I have a philosophical obstacle to get over to submit anything) | 22:17 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!