*** brocka has joined #trustable | 01:23 | |
*** brocka has quit IRC | 01:28 | |
*** brocka has joined #trustable | 03:24 | |
*** brocka has quit IRC | 03:29 | |
*** brocka has joined #trustable | 07:25 | |
*** brocka has quit IRC | 07:59 | |
*** brocka has joined #trustable | 08:15 | |
*** brocka has quit IRC | 08:35 | |
*** toscalix_ has joined #trustable | 08:45 | |
*** toscalix_ has quit IRC | 08:46 | |
*** toscalix_ has joined #trustable | 08:49 | |
*** toscalix_ has quit IRC | 09:12 | |
*** toscalix has joined #trustable | 09:13 | |
*** sambishop has joined #trustable | 09:19 | |
reiterative | In 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 #trustable | 09:56 | |
*** sambishop has quit IRC | 09:59 | |
*** sambishop_ has quit IRC | 10:10 | |
*** sambishop_ has joined #trustable | 10:12 | |
*** sambishop_ has quit IRC | 10:44 | |
*** sambishop has joined #trustable | 10:44 | |
reiterative | Update: 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.md | 10:45 |
paulsherwood | reiterative: maybe now would be a good time to adjust the readme of that repo? | 10:46 |
reiterative | Agreed. I'll get on it. | 10:46 |
paulsherwood | elsewhere someone has just mentioned https://reuse.software | 10:47 |
paulsherwood | and i'm assuming that we should add that project to our growing list of relevant/complementary work | 10:48 |
toscalix | reiterative: where do you see resilience in that picture? It is an important aspect when you think about continuous delivery as practice | 11:08 |
toscalix | it fact, many claim that optimising for resilience is more important than for robustness (reliability and durability in the new version) | 11:09 |
toscalix | when it comes to software production processes | 11:10 |
reiterative | I 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 |
toscalix | or are we assuming resilience is a process property and not a system one | 11:11 |
reiterative | Snap! | 11:12 |
reiterative | Which doesn't mean that it isn't relevant or important - just part of a different picture | 11:12 |
toscalix | I think resilience can be also a system property. | 11:35 |
reiterative | What is your definition of resilience in this context? | 11:37 |
toscalix | and I think that durability and reliability deals with how robust is a system. Resilience deals with how a system can "absorb changes" | 11:37 |
toscalix | it is not a specific one. Resilience is the ability to “absorb or avoid damage without suffering complete failure“ | 11:38 |
toscalix | that is the one I intend to use in the metrics doc | 11:38 |
toscalix | Wikipedia one | 11:38 |
toscalix | in CD there is a concious and specific distinction between reliability and resilience | 11:39 |
toscalix | because both concepts leads you to a complete different strategy when it comes to process optimization to achieve desired stability and thorughput | 11:40 |
toscalix | in safety critical resilience is an important concept too | 11:40 |
toscalix | and I wonder if we are not considering for a specific reason or we simply haven't considered at all before | 11:41 |
reiterative | I 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 |
reiterative | Although my diagram is crowded enough already! | 11:48 |
toscalix | ok then | 11:50 |
reiterative | (That's definitely not a reason to leave it out!) | 11:50 |
*** traveltissues has joined #trustable | 11:53 | |
reiterative | I'm now tempted to wrap Reliability, Durability and Resilience up into Functionality | 11:56 |
toscalix | why 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 |
toscalix | I mean, it is more a kind of mindset than a real change in the process we are following | 12:00 |
reiterative | Yes, that makes sense | 12:00 |
toscalix | I 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 advancing | 12:02 |
toscalix | maybe a general concept of "version" would help to keep a check list of tasks "on sync" | 12:02 |
toscalix | we have a white paper, a website, spta, the nomenlcature doc, the hypothesis one, the goals.... | 12:03 |
toscalix | we probably need a structured index | 12:04 |
toscalix | in the website and/or readme.md | 12:04 |
reiterative | Yes, 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 snapshot | 12:06 |
persia | https://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 |
reiterative | Not yet, but that's my next step | 12:21 |
persia | Remember that there is an information horizon that happens when a History is Published. | 12:26 |
reiterative | Yes, 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 |
persia | I'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 |
persia | So 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 |
persia | I can imagine a way to verify Reproducibility, but I'm not sure how to verify Constructability, Updatability, Verifiability, or Testability | 12:58 |
*** sambishop_ has joined #trustable | 13:27 | |
*** sambishop has quit IRC | 13:29 | |
*** sambishop_ has quit IRC | 14:01 | |
*** sambishop_ has joined #trustable | 14:01 | |
*** sambishop_ has quit IRC | 14:40 | |
*** traveltissues has quit IRC | 14:42 | |
*** traveltissues has joined #trustable | 14:42 | |
*** sambishop_ has joined #trustable | 14:52 | |
*** sambishop_ has quit IRC | 15:00 | |
*** sambishop has joined #trustable | 15:00 | |
toscalix | reiterative, 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 resilience | 15:13 |
*** sambishop has quit IRC | 16:11 | |
*** toscalix has quit IRC | 16:55 | |
*** toscalix_ has joined #trustable | 16:56 | |
*** traveltissues has quit IRC | 18:55 | |
*** traveltissues has joined #trustable | 19:11 | |
*** sambishop has joined #trustable | 19:21 | |
*** traveltissues has quit IRC | 19:26 | |
*** sambishop has quit IRC | 19:49 | |
*** toscalix_ has quit IRC | 20:13 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!