If necessary, we will create short-term private branches for specific vendor projects that involve pre-production hardware. These branches will be merged back into the main kernel as soon as possible, using one code review per CL so that all code in our master branch is either from upstream or code reviewed. The intent of these private branches is to enable code review and project status monitoring of code that cannot be publicly released yet, due to NDA. The intent is specifically not to use these branches to keep changes that are shipping to customers.
Any code submitted should be done as one Git commit per logical change, with a good description. (See Documentation/SubmittingPatches in the kernel tree.) We may create temporary public branches for the purpose of working together on code review and integration.
DCO (documented certificate of ownership) as a signoff of ownership. Each commit will contain the signoff of the code author/committer and the ACK of the patch approver. Code should be submitted under the Chromium contributor license agreement.
Here's an example of a changelog entry:
All kernel code (including backports from upstream) contributed by Google or partners will include a classification tag in the first line of the commit log. The classification will be useful when the maintainer needs to rebase to a newer kernel; the tag is also needed for proper attribution. The tag is in ALL_CAPS_UNDERSCORE, is followed by a colon, and is at the beginning of the first line. The first line from each commit should be a summary.
Code contributed by the Chromium community will use the tag CHROMIUM. For example:
Code backported from upstream (Linus's tree) will use the tag UPSTREAM. For example:
Code backported from an upstream maintainer tree will use two tags. For example:
Code ported from a Linux distribution tree or other non-upstream tree will also use an appropriate tag. For example:
All third-party vendors are expected to supply updated versions of their code against every new mainline kernel version (for example, at 3.2, 3.3, and so on) within 14 days of its release, if the code is not already upstream.
We will not support initial RAM disks (initrd) for the general kernel, but will need them on recovery image kernels as well as for the factory install flow.
The tradeoff for using 64 bits is additional power consumption and memory usage, in return for greater performance.
We realize that not having swap will limit how many tabs a user can keep open and the amount of anonymous memory a process can allocate. Aggregate size of anonymous memory in the system will be limited to the size of RAM. We may revisit this decision in future releases.
To make this more maintainable, config files will be assembled from sections to avoid repeated data.