README (969bc941052c29943dfb40d55089dc56fa46be57) README (2ad72058bc680e30f084e9f9ba8ceb0f77386821)
1Illumos Gate README - July 29, 2010.
1illumos gate README - Sept 12, 2010.
2
2
3This is the Illumos gate. It contains the following subdirectories:
3This is the illumos gate. This is the illumos source tree. It contains
4the following subdirectories:
4
5
5 - usr/src -- this is a clone (with changes) of the Oracle ONNV gate.
6 We should avoid making too many disruptive changes here. It
7 will be periodically synced with ONNV.
6 usr/src - The actual source code
8
7
9 - usr/illumos -- this is the set of bits that we deliver, which are not
10 yet integrated into the onnv tree. This may include various
11 testing bits, etc. These bits (for whatever reason), are things
12 that we think are inappropriate for inclusion in the upstream and
13 really are specific to illumos.
8 exception_lists - These are lists of exceptional cases
9 used to limit noise during builds.
10 Ideally this directory would consist of
11 only empty files.
14
15Integration Rules:
16
12
13Integration Rules:
14
17 All changes must have been reviewed, and (for the interim only!)
18 approved by the gatekeeper (below). A code review may be performed
19 by someone other than the gatekeeper, but the final integration should
20 still be approved by the gatekeeper. (Think CRT advocate for now.)
21 The gatekeeper will want to see your webrev and hg outgoing -v.
15 All changes must have been reviewed, and approved by and advocate
16 (below). A code review may be performed by someone other than the
17 advocate, but the final integration should still be approved by the
18 advocate.
22
19
20 The advocate will want to see your webrev and hg outgoing -v. The
21 advocate will also ask about your testing, and may ask to see your
22 build logs.
23
23 All changes must adhere to typical ON style and quality rules.
24 For example, pass full cstyle, applicable lint rules, etc.
25
24 All changes must adhere to typical ON style and quality rules.
25 For example, pass full cstyle, applicable lint rules, etc.
26
26 All commits must include either a CDDL or BSD/MIT license, unless
27 approved otherwise by the gatekeeper. CDDL licensed changes must
28 be backed by a Sun Contributor Agreement, so that the changes can
29 be contributed to the upstream OpenSolaris consolidation.
27 All commits must include either a CDDL license, unless
28 approved otherwise by the gatekeeper, or the modified code
29 already carries a different license. Exceptions shall require
30 the approval of the gatekeeper.
30
31 Hg commits should have comments of the following form:
32
33 1234 This is a sample bug report synopsis
34 4567 If you have a second bug synopsis...
35 Reviewed by: codereviewer@somewhere.net
36 Approved by: gatekeeper@somewhere.else.com
37
31
32 Hg commits should have comments of the following form:
33
34 1234 This is a sample bug report synopsis
35 4567 If you have a second bug synopsis...
36 Reviewed by: codereviewer@somewhere.net
37 Approved by: gatekeeper@somewhere.else.com
38
39 Each commit must have at least one bug id that is listed in the
40 illumos-gate project at www.illumos.org.
41
38Branches:
39
40 Please talk to the gatekeeper about personal branches. In general,
41 they will be allowed as long as we don't go *too* wild on them.
42
43Gatekeeper: garrett@nexenta.com (Interim)
44IRC channel: #illumos on irc.freenode.net
45Mailing list: developer@lists.illumos.org
46
42Branches:
43
44 Please talk to the gatekeeper about personal branches. In general,
45 they will be allowed as long as we don't go *too* wild on them.
46
47Gatekeeper: garrett@nexenta.com (Interim)
48IRC channel: #illumos on irc.freenode.net
49Mailing list: developer@lists.illumos.org
50