[trustable-software] Exploring the "Hypothesis for software to be trustable"

Daniel Silverstone daniel.silverstone at codethink.co.uk
Wed Jan 3 17:24:39 GMT 2018


On Wed, Jan 03, 2018 at 16:42:08 +0000, Paul Sherwood wrote:
> > This seems to stand alone rather than being linked in.  How about adding
> > to
> > the top of t.software:
> > 
> > - t.software is composed of one or more t.changes
> 
> How would this work for the situation where we are trying to retrofit our
> ideas/process/magic on existing software?

In the simplest sense, when introducing this to existing software we flip it
around and say there's an empty project using this process, into which we make
a single t.change which introduces the current state of the t.software.

> > > - adding t.process to a mature infrastructure project must
> > 
> > Why 'infrastructure' here?
> 
> I need to find better wording. My thought was for software that's already
> trusted, irrespective of our attempts to classify/measure/improve it.

Right, but why limit it to infrastructure projects rather than any software
project?

- adding t.process to an existing, potentially trusted, project must

?

-- 
Daniel Silverstone                           http://www.codethink.co.uk/
Solutions Architect               GPG 4096/R Key Id: 3CCE BABE 206C 3B69



More information about the trustable-software mailing list