IRC logs for #trustable for Monday, 2019-03-11

*** brocka has joined #trustable01:23
*** brocka has quit IRC01:28
*** brocka has joined #trustable03:24
*** brocka has quit IRC03:29
*** brocka has joined #trustable07:25
*** brocka has quit IRC07:59
*** brocka has joined #trustable08:15
*** brocka has quit IRC08:35
*** toscalix_ has joined #trustable08:45
*** toscalix_ has quit IRC08:46
*** toscalix_ has joined #trustable08:49
*** toscalix_ has quit IRC09:12
*** toscalix has joined #trustable09:13
*** sambishop has joined #trustable09:19
reiterativeIn case anyone hasn't already seen it on the mailing list, I have a new MR up on the trustable/documents repo, which is an attempt to refine the Trustable hypothesis and extend its applicability: https://gitlab.com/trustable/documents/merge_requests/55. Feedback very welcome.09:29
*** sambishop_ has joined #trustable09:56
*** sambishop has quit IRC09:59
*** sambishop_ has quit IRC10:10
*** sambishop_ has joined #trustable10:12
*** sambishop_ has quit IRC10:44
*** sambishop has joined #trustable10:44
reiterativeUpdate: the MR has just been approved by Paul S, so you can see the new material here: https://gitlab.com/trustable/documents/blob/master/markdown/hypothesis-elements.md10:45
paulsherwoodreiterative: maybe now would be a good time to adjust the readme of that repo?10:46
reiterativeAgreed. I'll get on it.10:46
paulsherwoodelsewhere someone has just mentioned https://reuse.software10:47
paulsherwoodand i'm assuming that we should add that project to our growing list of relevant/complementary work10:48
toscalixreiterative: where do you see resilience in that picture? It is an important aspect when you think about continuous delivery as practice11:08
toscalixit fact, many claim that optimising for resilience is more important than for robustness (reliability and durability in the new version)11:09
toscalixwhen it comes to software production processes11:10
reiterativeI think it potentially fits under both Durabilty and Reliability - but as I understand it, it's more a characteristic of process than software.11:11
toscalixor are we assuming resilience is a process property and not a system one11:11
reiterativeSnap!11:12
reiterativeWhich doesn't mean that it isn't relevant or important - just part of a different picture11:12
toscalixI think resilience can be also a system property.11:35
reiterativeWhat is your definition of resilience in this context?11:37
toscalixand I think that durability and reliability deals with how robust is a system. Resilience deals with how a system can "absorb changes"11:37
toscalixit is not a specific one. Resilience is the ability to “absorb or avoid damage without suffering complete failure“11:38
toscalixthat is the one I intend to use in the metrics doc11:38
toscalixWikipedia one11:38
toscalixin CD there is a concious and specific distinction between reliability and resilience11:39
toscalixbecause both concepts leads you to a complete different strategy when it comes to process optimization to achieve desired stability and thorughput11:40
toscalixin safety critical resilience is an important concept too11:40
toscalixand I wonder if we are not considering for a specific reason or we simply haven't considered at all before11:41
reiterativeI have considered it - Jeff also mentioned it - but I have been consciously trying to avoid adding too many aspects - I already think that Reliability and Durability are sub-aspects of Functionality. Burt if we are going to distinguish them, then perhaps we should include Resilience as well...11:47
reiterativeAlthough my diagram is crowded enough already!11:48
toscalixok then11:50
reiterative(That's definitely not a reason to leave it out!)11:50
*** traveltissues has joined #trustable11:53
reiterativeI'm now tempted to wrap Reliability, Durability and Resilience up into Functionality11:56
toscalixwhy not consider resilience as a concept to evaluate for the next version? Instead of aiming to cover everything right in each version, assume it will evlove, make comments on what will be considered for the next version, and move on.11:59
toscalixI mean, it is more a kind of mindset than a real change in the process we are following12:00
reiterativeYes, that makes sense12:00
toscalixI think that it is more urgent to update the website and the readme with the conclusions we have reached the last few months (consolidate where we are now) than keep advancing12:02
toscalixmaybe a general concept of "version" would help to keep a check list of tasks "on sync"12:02
toscalixwe have a white paper, a website, spta, the nomenlcature doc, the hypothesis one, the goals....12:03
toscalixwe probably need a structured index12:04
toscalixin the website and/or readme.md12:04
reiterativeYes, that is a good idea - I was just trying to decide how much I wanted to change in the existing material, but it might make more sense to preserve it all as coherent snapshot12:06
persiahttps://gitlab.com/trustable/documents/blob/master/markdown/hypothesis-elements.md just looks like a list of words to me.  Is there anything to tie it together?12:16
reiterativeNot yet, but that's my next step12:21
persiaRemember that there is an information horizon that happens when a History is Published.12:26
reiterativeYes, I haven't forgotten - that's one of the reasons why we need to map the kinds of evidence we need, so that we can understand how the information horizon might interfere with it. Hence I have been re-examining the elements that were identified in the original hypothesis, to encompass sources of evidence that were omitted (or excluded) and to show how they can combine to form a coherent (but frequently incomplete) overall map of trustability.12:41
persiaI'm confused by that.  My understanding was that when an Identity Consumes a History, the only information available is the History.  Given that a History is typically a collection of bits collected from some software system, I don't understand how *any* information passes the horizon: the Identity only has the assertions in the history and presumptive ability to check for consistency against other internal information (or other Consumed Histories).12:49
persiaSo I never expect a consumer to be able to discover who created/contributed to a work, the submitted opinions of any of those contributors, the history/track record of the software, or how it was created.  At best, the consumer has an attestation to those.12:51
persiaI can imagine a way to verify Reproducibility, but I'm not sure how to verify Constructability, Updatability, Verifiability, or Testability12:58
*** sambishop_ has joined #trustable13:27
*** sambishop has quit IRC13:29
*** sambishop_ has quit IRC14:01
*** sambishop_ has joined #trustable14:01
*** sambishop_ has quit IRC14:40
*** traveltissues has quit IRC14:42
*** traveltissues has joined #trustable14:42
*** sambishop_ has joined #trustable14:52
*** sambishop_ has quit IRC15:00
*** sambishop has joined #trustable15:00
toscalixreiterative, going back to the resilience discussion, you might want to refer to operability instead of resilience, not sure at this point. Resilience leads to focus on production risk management which leads you to, among other concepts, to software system operability. Maybe you want to start by oprability which in software is a more concrete concept than resilience15:13
*** sambishop has quit IRC16:11
*** toscalix has quit IRC16:55
*** toscalix_ has joined #trustable16:56
*** traveltissues has quit IRC18:55
*** traveltissues has joined #trustable19:11
*** sambishop has joined #trustable19:21
*** traveltissues has quit IRC19:26
*** sambishop has quit IRC19:49
*** toscalix_ has quit IRC20:13

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!