| | 1 | [[TOC]] |
| | 2 | = S3 !UltraCore = |
| | 3 | |
| | 4 | S3 !UltraCore (ucore) is a special branch of the S3 project: |
| | 5 | |
| | 6 | - [https://launchpad.net/sahana/ucore] |
| | 7 | |
| | 8 | The S3 !UltraCore series contains the pure essentials of S3. It is meant to be truly fast, clean and minimalistic - and the most rigorously tested and quality-approved S3 release: a rock-solid foundation for the development of S3-based applications. |
| | 9 | |
| | 10 | == Goals == |
| | 11 | |
| | 12 | "!UltraCore" shall be a quality mark for reliability, performance, scalability and standard-conformance. |
| | 13 | |
| | 14 | It is not necessarily a predicate of feature-richness or sophisticated screen solutions. The "!UltraCore" doesn't need to look especially pretty to the user or provide impressive complex functionality - in the first line it has to be bullet-proof. |
| | 15 | |
| | 16 | S3 !UltraCore is not a separate project - it is a "purification" branch (in contrast to "development" branches) of the S3 core, with the goal to create: |
| | 17 | 1. a quality standard for stability, performance and standard-conformance |
| | 18 | 2. a rock-solid foundation for the development of S3 applications |
| | 19 | |
| | 20 | Take "fast, clean, and minimalistic" as mantra. |
| | 21 | |
| | 22 | == Code Proposals == |
| | 23 | |
| | 24 | Consequently, the ucore branch is not open for contributions, and no code gets developed for ucore - only code from the main trunk can be proposed for ucore. That means, the code has to pass at least the trunk entry criteria (including all SSF requirements) before it can be proposed at all. |
| | 25 | |
| | 26 | Any piece of code that shall be proposed for ucore must: |
| | 27 | a) be core (meaning, relevant for all S3-based applications) |
| | 28 | b) be in trunk |
| | 29 | c) have a complete developer documentation (including blueprint) |
| | 30 | d) have a maintainer (or a maintainer team) |
| | 31 | |
| | 32 | The maintainers can submit an informal proposal to the !SahanaPy developer's mailing list to take up their code into ucore. |
| | 33 | |
| | 34 | == Acceptance Criteria == |
| | 35 | |
| | 36 | A piece of code can be accepted for ucore, if: |
| | 37 | a) it works perfectly with the existing ucore code |
| | 38 | b) there are no open bugs related to that code in trunk |
| | 39 | c) there are no workarounds or temporary solutions in that code |
| | 40 | d) the code has sucessfully passed some destructive testing (yet to be defined), and at best stood a real-world deployment |
| | 41 | e) the code follows strictly all coding conventions (yet to be defined) |
| | 42 | |
| | 43 | If code gets accepted for ucore, then that does not mean that all updates of that code will automatically be accepted as well - any update version of the |
| | 44 | code has to pass the whole procedure again. |
