Platform Team/Server Kit/Architecture: Difference between revisions

Line 1:

== Intention ==

* ~~Having common~~ project~~(s)~~ and ~~friendly~~ support of customization on purpose in downstream products:

* Common project within Sugar Labs to keep core development process in one place;

* It is not about configuring and supporting the whole server at school from scratch but about having a set of tough, local, doing its job well modules that might be included/excluded in downstream solutions;

* Friendly support of customization on purpose in downstream products:

** Modularizing, when components might be included on purpose to fulfill local needs,

** Not patching in downstream but supplementing the upstream, e.g., install upstream packages and just add new packages with local customization or overrides (but not overriding installed files to let PMS work smooth) of upstream,

** Provide useful API for components;

* Be a GNU/Linux distribution agnostic. It doesn't make much sense in case of having only Server on a school server installed from an iso but it makes sense sugar-serve will be installed in already configured and maintained environment or if downstream organizations ship their products based on the Server and having particular GNU/Linux ~~distribution is important;~~

* Be a GNU/Linux distribution agnostic, different deployment might decide to use different GNU/Linux distributions.

* It is not only about supporting XO laptops but about any Sugar based environments;

* Up to 1000 students per server.

@@ Line 1: / Line 1: @@
 == Intention ==
-* Having common project(s) and friendly support of customization on purpose in downstream products:
+* Common project within Sugar Labs to keep core development process in one place;
+* It is not about configuring and supporting the whole server at school from scratch but about having a set of tough, local, doing its job well modules that might be included/excluded in downstream solutions;
+* Friendly support of customization on purpose in downstream products:
 ** Modularizing, when components might be included on purpose to fulfill local needs,
 ** Not patching in downstream but supplementing the upstream, e.g., install upstream packages and just add new packages with local customization or overrides (but not overriding installed files to let PMS work smooth) of upstream,
 ** Provide useful API for components;
-* Be a GNU/Linux distribution agnostic. It doesn't make much sense in case of having only Server on a school server installed from an iso but it makes sense sugar-serve will be installed in already configured and maintained environment or if downstream organizations ship their products based on the Server and having particular GNU/Linux distribution is important;
+* Be a GNU/Linux distribution agnostic, different deployment might decide to use different GNU/Linux distributions.
 * It is not only about supporting XO laptops but about any Sugar based environments;
 * Up to 1000 students per server.