hi Alex; this is great material, thanks for sending it. On 4 September 2014 18:05, Alexander Larsson <[email protected]> wrote:
> 1. A platform definition ... > 2. A reference implementation ... > 3. A SDK and other tooling ... > 4. IPC stability guarantees ... > 5. Sandboxing APIs ... also: 6. A compliance test suite/document we want: * application developers to check that their application will correctly run on GNOME, and be able to ensure that their application appears in the Software installer, whatever run-time they opt to use. * OEMs and OSVs (and I put distributions in the latter category) to verify (even automatically) that they are indeed deploying GNOME in a way that makes both the OS and the applications work as best as possible, so that they can create their own overlay on top of the GNOME run-time. * the engagement team to have a list of compliant environments that are deploying GNOME as expected, as well as a list of well-behaved applications to point and showcase for ISVs to use. * the QA team to be able to run a compliance test suite (and possibly a QA "script" of actions) on our run-time releases to verify that the functionality is available and that there are no regressions. example 1: if Fedora wants to ship a run-time that builds on top of the GNOME reference one then they will have to know what capabilities can be added without breaking the underlying environment. example 2: if Endless is shipping an OS that is based on GNOME, they need to provide a compliance QA document for verifying that the installation on the factory floor is executed correctly, which means a compliance document with a bunch of test units. ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
