Re: Please submit platform trees for inclusion in arm-soc.git v3.1

[Barry Song]

Hi Arnd,

2011/7/2 Arnd Bergmann <arnd@xxxxxxxx>:
> 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.

i hope we can catch this cycle to see CSR platform merged in 3.1.
after you review and agree on v3 patch i sent today, i will send you a
pull request againest Linus' tree.

>
> 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@xxxxxxxxxx' 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
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
Thanks
Barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/