| *** AlisonChaiken has quit IRC | 02:47 | |
| *** LaurenceUrhegyi has joined #trustable | 08:22 | |
| *** ctbruce has joined #trustable | 08:34 | |
| *** toscalix has joined #trustable | 09:23 | |
| *** mdunford has quit IRC | 09:29 | |
| *** locallycompact has joined #trustable | 10:47 | |
| *** ctbruce has quit IRC | 10:52 | |
| *** ctbruce has joined #trustable | 11:07 | |
| *** ctbruce has quit IRC | 11:17 | |
| *** ctbruce has joined #trustable | 11:18 | |
| *** bruceunderhill has joined #trustable | 12:09 | |
| *** ctbruce has quit IRC | 12:09 | |
| *** bruceunderhill has quit IRC | 15:16 | |
| LaurenceUrhegyi | persia: are we saying the TSW has be to machine readable? If so, for my benefit, could you explain why? | 15:18 |
|---|---|---|
| persia | I'm not sure I understand the question. | 15:19 |
| persia | In my mind, any requirements for a given system should be machine-readable, to allow automation to determine if they have been met. | 15:19 |
| persia | As a result, if one wishes to be able to require that a system produces software that can be audited for trust, then one needs to produce a set of requirements defining what that means, and those requirements need to be machine-readable. | 15:20 |
| persia | As such, I think the end goal is to create machine-readable requirements along with associated tooling to allow this to be tested. I'm not sure if the TSW is this end deliverable. | 15:20 |
| *** ctbruce has joined #trustable | 15:21 | |
| persia | Does that approach an answer to your question? | 15:22 |
| *** ctbruce has quit IRC | 15:23 | |
| LaurenceUrhegyi | persia: ok, I see that, yes. My concern was that, in focusing too much on getting the UML right we may have overlooked the 'bigger picture' in some places, and I was wondering if we need to make it fully machine readable at this point, rather than focusing on nailing down the principles / philosophy / methodology. | 15:23 |
| LaurenceUrhegyi | Since our first objective is to make it readable for humans. | 15:24 |
| *** ctbruce has joined #trustable | 15:24 | |
| LaurenceUrhegyi | But I do see the point a bit clearer now. | 15:24 |
| persia | I believe that formalism encourages clarity of thought. That said, it may be that we're operating at too high a level of specification for our current thinking, in which case it makes sense to step back, and determine what we are actually trying to describe. | 15:24 |
| persia | For example, although I'd like there to be sequence diagrams, I don't think we know enough to write them yet, hence my call for activity diagrams recently. | 15:25 |
| LaurenceUrhegyi | 'operating at too high a level of specification for our current thinking' - we may have slipped into that, yes. | 15:26 |
| LaurenceUrhegyi | But that's the idea of 'commit often' isn't :) | 15:26 |
| persia | I do not see the relation between those concepts. | 15:26 |
| LaurenceUrhegyi | I just meant 'it's not perfect as of yet, but we'll take the feedback and amend' | 15:28 |
| LaurenceUrhegyi | that's all | 15:28 |
| persia | Oh, certainly. | 15:29 |
| persia | Going back to the level of specification: I'm not sure how much higher-level we can get from component diagrams or activity diagrams without getting very fuzzy indeed (e.g. use case diagrams). | 15:30 |
| * paulsherwood notes that jmacs and others expressed that we need more input from safety/critical community - we're getting it :-) | 15:30 | |
| persia | Yes. The Eurofighter case study is very interesting, and targets some of the deeper concepts we're exploring here. | 15:31 |
| * LaurenceUrhegyi reminds himself to re-read the Eurofighter case in more detail | 15:34 | |
| persia | To me, the most exciting part was that the requirements for how a project is developed/tested changed in the middle of a project, without significant changes to the detailed requirements for the project itself. | 15:37 |
| paulsherwood | this seems quite common | 15:37 |
| persia | paulsherwood: Really? My prior experience usually involved changes to the requirements for the system under development, with frozen requirements on the method of development for the life of the project (so, many projects being developed under grandfathered processes) | 15:39 |
| persia | But I admit that most of that is in industries where safety has not been a concern (although it arguably should have been) | 15:39 |
| *** sambishop has quit IRC | 16:04 | |
| *** sambishop has joined #trustable | 17:04 | |
| *** sambishop has quit IRC | 17:13 | |
| paulsherwood | LaurenceUrhegyi, jmacs - pls can someone provide clive with details for today's studygroup meeting? | 17:15 |
| jmacs | I didn't think we were having one | 17:17 |
| paulsherwood | ah, ok... | 17:17 |
| chrispolin | Nor did I, I thought it was next week. | 17:17 |
| *** ctbruce has quit IRC | 17:17 | |
| * chrispolin searches emails. | 17:17 | |
| paulsherwood | robert has replied, never mind ;) | 17:18 |
| *** sambishop has joined #trustable | 17:18 | |
| *** locallycompact has quit IRC | 17:28 | |
| *** toscalix has quit IRC | 18:05 | |
| *** LaurenceUrhegyi has quit IRC | 18:14 | |
| jmacs | Does Patchwork allow you to do anything active with patches or store any information? It looks to me like it just reads mailing lists and presents them in a more pleasant way | 18:24 |
| persia | Maintainers can set state (Accepted, Rejected, Under Review). | 18:36 |
| * persia forgets whether assignment is patchwork metadata or a result of specially formatted mail | 18:37 | |
| persia | The readme in the github repo has a link to a presentation from last year's FOSDEM about adding features to patchwork to compete with gerrit, etc. | 18:38 |
| persia | Yes. Delegation is also a patchwork faeture, rather than being a side-effect. | 18:42 |
| persia | But the talk implies CI integration, multiple reviewers, etc. are features under development. | 18:43 |
| persia | The above made me think a bit more about generalisation of the requirements for the components in a system, which led me to review http://www.trustable.io . Based on the central premise, I've drafted http://paste.baserock.org/hevevubiya to cover some of the implications, but I realise that I have no idea how to assert that it is possible to know what software does. | 19:06 |
| persia | We can test to make sure it does the things we want, and we can test to make sure it doesn't do the things we don't want, but I'm not sure how to usefully organise tests to find out what something is capable of doing (especially if the software being tested doesn't want to explain itself). | 19:06 |
| persia | Any suggestions? Maybe something related to static analysis of potential entry points, and comparison to test coverage (although this can still be obfuscated by systems (e.g. easter eggs))? | 19:07 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!