README.md

   1 illumos-unleashed
   2
   3 We think that operating systems are very exciting to work on; In particular,
   4 we enjoy working with descendants of OpenSolaris.  Unfortunately, we feel
   5 that the major OpenSolaris fork - illumos - has adopted a contribution
   6 process that hinders development and discourages new contributors from
   7 coming back with more code changes.  Therefore, we created this fork to try
   8 to address these issues.
   9
  10 Goals
  11 =====
  12
  13 While the full list of goals is constantly evolving, the following is a list
  14 of the basic goals which we always strive for.
  15
  16 1. The contribution process must be simple and must encourage new
  17    contributors to repeatedly contribute.
  18 2. XXX: describe that we want releases
  19 3. Unleashed aims to be a modern operating system base.
  20   1. Modern compiler support.  Currently, we support only gcc 4.4.4, however
  21      we hope to allow a wider range of gcc versions.  Eventually, we would
  22      like to be able to use clang as well.
  23   2. The UNIX environment has changed drastically over the past 20 years.
  24      As a result, we hope to ship an environment that provides the comforts
  25      of modern UNIX, yet maintain the unique features we inherited that set
  26      us apart from other UNIX systems out there.
  27   3. POSIX has won.  Therefore, when it does not hinder usability (see item
  28      3.2), we want a system that is POSIX compliant without having to jump
  29      through special hoops (e.g., setting $PATH, or providing extra compiler
  30      flags).
  31   4. We do *not* support "extreme legacy".  While support for legacy
  32      interfaces and binaries is important, it must be done in moderation.
  33      Therefore, old interfaces may be removed from time to time.  Interface
  34      deprecation will be clearly communicated through release notes.
  35 4. Maintaining code is hard enough when the code is squeaky clean.  To make
  36    our job easier, we try to get the code clean when first committing it -
  37    even if it delays the commit a little bit.  In other words, we care about
  38    more than just that the code works - we want code we can (for the most
  39    part) be proud of.
  40 5. XXX: describe the amount of self-contained-ness
  41
  42 Notes for review:
  43
  44 * I did not include the "we're not SunOS 5.11" because that seems like a too
  45   specific of a goal instead of a general direction we want to go in.  I
  46   think that the above set of goals makes it obvious enough that we're
  47   willing to break uname.
  48
  49 Rules
  50 =====
  51
  52 The community organization is based on the FreeBSD community.  (See
  53 docs/organization.md for a more thorough description.)  This style of
  54 community reflects our belief that our community members can behave
  55 responsibly both when communicating with other as well as when committing
  56 code to the repository.  To help guide newcomers, we have created a Code of
  57 Conduct (see docs/code-of-conduct.md) that we expect everyone to abide by.
  58
  59 Commits
  60 -------
  61
  62 Commits are cheap.  Modern revision control systems (e.g., git) handle large
  63 numbers of commits very well.  Therefore small changes that are encouraged
  64 (instead of "mega commits" that seem to touch half the code base).  Smaller
  65 commits make it easier to search through commit history to see what other
  66 parts of the repository were changed as part of the change.
  67
  68 Each commit should build and boot.  Obviously, running nightly and a full
  69 set of tests for each commit is not necessarily practical, however one
  70 should try to avoid commits that break the build.  (Commits that don't build
  71 or boot make it harder to bisect the history to find bad commits.)
  72
  73 For the most part, we use a Linux kernel-style commit messages.  If there is
  74 a bug number reference it.  For example:
  75
  76     subsys: frob the input 7 times
  77
  78     frobbing less than 7 times leads to information disclosure
  79     vulnerability.
  80
  81     illumos bug #123
  82
  83     Spelling of comments fixed up by: Committer Developer <c.d@example.com>