IRC logs for #trustable for Wednesday, 2018-02-21

*** toscalix has joined #trustable09:04
*** locallycompact has quit IRC10:08
*** locallycompact has joined #trustable10:09
*** persia has quit IRC12:46
*** persia has joined #trustable12:47
*** chrispolin has quit IRC13:22
*** ltu has quit IRC13:22
*** chrispolin has joined #trustable13:24
*** Guest1639 has quit IRC13:31
*** tiago has joined #trustable13:31
*** laurenceurhegyi has joined #trustable13:36
*** locallycompact has quit IRC14:24
*** locallycompact has joined #trustable14:24
*** bapophis has joined #trustable15:15
paulsherwoodbapophis: 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
bapophisi'll need some time to read these and i'd like to finish my current, what's your cut-off time15:18
paulsherwoodno rush15:18
paulsherwoodi'll probably work on revised patch tmrw or fri15:19
* persia is somewhat disappointed to get a "you don't have permission" message from that URL.15:22
paulsherwoodinteresting15:24
paulsherwoodpersia: pls try now?15:24
persiapaulsherwood: Works now.15:25
paulsherwoodpersia: ack, thanks. sorry for the mixup15:26
persiaFor 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 done15:28
*** laurenceurhegyi is now known as ltu15:29
paulsherwoods/done/started/15:36
paulsherwoodyup to transparency, that was simply a mistake15:36
*** locallycompact has quit IRC16:45
*** toscalix has quit IRC17:45
bapophispaulsherwood, i'm happy with those answers now but added some thoughts20:06
persiabapophis: 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
persiaFor 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
bapophisi think i added something to that effect at https://gitlab.com/trustable/workflow/merge_requests/6#note_6003115320:10
persiaThat is precisely the thing to which I was responding :)20:11
persiaThe main point of my statement was to introduce t.policy, which governs the review process.20:12
bapophisok, i agree with you20:12
bapophisi was also not aware of that, i've only just started looking at this project and haven't had much time to poke it20:12
persiaI 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
bapophisit seems like there need to be policy or high-level frameworks though20:14
persiaAlso, 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
persiaYes.  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:submittable20:16
persiaBut it would be nice to have a more generic system, ideally with consensus by all git users about notation and storage20:17
persia(sadly, git-configured git servers like gerrit and gitano all seem to have different custom ways to configure permissions, etc.)20:17
bapophisi 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-trivial20:20
persiaI think there are two separable factors.20:21
persiaFirstly, there is a state condition of whether a requirement has been implemented.20:21
persiaChanges to unimplemented requirements are unimportant.  Changes to implemented requirements can cause regressoin.20:21
persiaWhere 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
persiaSo, 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
persiaThis 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
persiaBecause 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
persiaOne 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
persiaBut 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
persiaAnyway, it's messy.  My thoughts here aren't complete.20:26
bapophisi think that has the potential to end up jamming the process20:28
persiaYep.  That's the hard part.20:28
persiaThe other possibility is to have a requirements tracker of some sort that marks requirements as met once impleentations have merged.20:28
bapophisi think this would be more clear with an abstract model20:29
persiagating then depends on a) compliance with all previously implemented requirements and b) compliance with any requirement implemnented by the new change.20:29
persiaUnfortunately, 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
persiaHow do you mean more abstract?20:31
persiaWhile an implementation as a merkle tree is handy, I don't think it's important to the problem.20:32
persiaBut 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
persiacalling 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
bapophiswell that's part of my point, language can be messy on these topics, i'd find it useful to make an object representation20:35
persiaAh, 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 result20:36
bapophisperhaps. but i've been thinking about this class of problems for about 15min so we may have to meet in the middle20:40
persiaHeh, yep.  If you do put together an object model, I'd be delighted to see it.20:41
paulsherwoodinteresting 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) describing21:44
persiapaulsherwood: 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
persiaI 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
persiaIf 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!