lkml.org 
[lkml]   [2011]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectPlease submit platform trees for inclusion in arm-soc.git v3.1
Date
Dear subarchitecture maintainers,

Time is running out for the current cycle, so any changes that you
want to see merged in linux-3.1 through the arm-soc tree should be
submitted in form of pull-requests very soon.

We currently have three per-subarchitecture branches (omap, stericsson,
zynq) and there is plenty of room for more.

The rules are roughly:

* We are here to help subarchitecture maintainers coordinate the merging
into the upstream torvalds/linux-2.6 tree. If we are not helpful, do
let us know.

* We are also there to prevent crap from getting merged. If you see
patches in someone else's pull request that shouldn't be there,
let us know, too.

* If you don't hear back from anyone within a few days, send a friendly
reminder.

* If you currently merge your patches upstream through RMK's tree,
you can keep doing so.

* All patches need to have been reviewed properly and are considered
ready for the next merge window.

* Once a patch gets into arm-soc, it stays in and you have to submit
follow-up patches for fixing bugs, not send replacement patches.

* If there is a serious problem with a patch that was already merged,
it will get reverted. If there is a serious problem with an entire
branch, it will not make it in the merge window unless the problems
are addressed.

* Group patch series by intention, e.g
* bug fixes
* cleanups and simplifications
* conversion to device tree
* support for new features
...
Don't worry if a pull request for one branch only has a single commit.
We can easily group it with similar branches when submitting onward.

* There is a single master branch that contains a merge of all the
other branches that are intended for the next merge window. This
branch is not yet part of linux-next, but will be. Before sending
a pull request, check if your branch merges with the master, and
mention any conflicts that when asking for a pull.
Small conflicts are ok, any serious conflicts need to be deal with
case-by case.

* Do not base code on arm-soc.git/master! All pull requests should be
relative to an -rc release in torvalds/linux-2.6.git when possible.
If you have dependencies on another branch, they need to be
mentioned in the pull request, so we can base it on top of that
branch, and wait for it to get merged upstream before asking Linus
to pull yours.

* Cleanups across multiple subarchitectures are ok, and should go into
one branch for the entire work.

* Bug fixes should be audited to see if they apply to stable kernels.
If you have a bug that should be applied on older kernel versions,
add 'Cc: stable@kernel.org' to the changelog.

* New subarchitectures need to use the flattened device tree and contain
no board specific files any more.

* New board support without using flattened device tree is ok in some
cases, especially when it's clear that you are making an effort to
avoid this in the future. Adding a lot of features and board code
is not ok when you don't also work on cleaning up the mess we already
have.

* Anything that moves code out of arch/arm is very welcome in general,
including:
* removal of nonworking and obsolete code that nobody will miss
* moving device drivers into their respective subsystems
* consolidation of identical code across boards and/or subarchitectures

* You can send pull requests at any time, there is no specific merge
window for the arm-soc tree. If you send them just before Linus
opens his merge window, or during that merge window, your patches will
probably have to wait for another release. This obviously depends
on the complexity and kind of patch. Simple bug fixes get always
forwarded for the current kernel, cleanups for the coming merge window,
and new features might need a bit extra time.

I have put everyone listed as a maintainer for arch/arm/mach-*/ on bcc
in this mail to let you know about it without having an endless cc list.

Arnd


\
 
 \ /
  Last update: 2011-07-01 20:23    [W:0.766 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site