You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@brooklyn.apache.org by he...@apache.org on 2016/02/01 18:31:17 UTC

[6/6] brooklyn git commit: Typo: "logic groupings" -> "logical groupings"

Typo: "logic groupings" -> "logical groupings"


Project: http://git-wip-us.apache.org/repos/asf/brooklyn/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn/commit/af2087cb
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn/tree/af2087cb
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn/diff/af2087cb

Branch: refs/heads/0.5.0
Commit: af2087cbd6f4921003d4d3001c9fe95f7fade02a
Parents: 14be897
Author: David Toy <d...@vidtoy.co.uk>
Authored: Thu Apr 18 19:52:26 2013 +0100
Committer: David Toy <d...@vidtoy.co.uk>
Committed: Mon Apr 22 12:52:48 2013 +0100

----------------------------------------------------------------------
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/brooklyn/blob/af2087cb/README.md
----------------------------------------------------------------------
diff --git a/README.md b/README.md
index 2cdc47a..35bfb06 100644
--- a/README.md
+++ b/README.md
@@ -25,7 +25,7 @@ In DevOps fashion, Brooklyn allows applications and roll-outs to be version cont
 
 Brooklyn enables [autonomic management](http://en.wikipedia.org/wiki/Autonomic_computing) of applications. (i.e. many small, local, distributed control loops).
 
-Management policies can be attached to every component part in an application, and to logic groupings of components (clusters, fabrics). Policies can implement both technical and non-technical (business) requirements.
+Management policies can be attached to every component part in an application, and to logical groupings of components (clusters, fabrics). Policies can implement both technical and non-technical (business) requirements.
 
 At runtime, policies have access to all aspects of the deployment, including deployment topology (hierarchical) and locations (machines, PaaSes, and jurisdictions), as well as scripts, instrumentation, and operational goals and constraints. This means that once the application is launched, the policies are all set to keep the application running optimally, based on whatever optimally means in that context.