lkml.org 
[lkml]   [2011]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] ARM Subarchitecture group maintainership
    On Wed, 18 May 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
    > On 10:47 Wed 18 May , Arnd Bergmann wrote:
    > > We will probably not be fully functional during the 2.6.40 merge window,
    > > but we are trying our best to be useful. For 2.6.41, my hope is that
    > > we can merge the bulk of the ARM subarchitecture changes through this
    > > tree. Once Linus is happy with the way that the process works, we can
    > > mandate that all ARM subarchitecture changes go through our tree, until
    > > then it stays voluntary.
    > How do you plan to manage with already sub arch maintainers?

    The sub arch maintainers are not replaced by this.

    > In my ming such tree could be good to organise cross arch drivers

    This is not about drivers. drivers need to move out of arch/arm into
    the proper drivers/subsystem where consolidation makes really sense
    even across architectures. We have already multiple drivers for the
    same stupid IP block in tree just because they were glued into
    different SoCs (ARM, x86, ....). That's not an ARM specific problem,
    it's all across the board, but on ARM it is very visible.

    > but for real arch specific the current workflow is good

    There is a difference between arch specific code - i.e. core ARM
    architecture code - and SoC specific code which goes into
    arch/arm/[mach|plat]-*. The core code was never and issue and we are
    not touching it as Russell is handling it perfectly. The real issue is
    the code in [mach|plat]-* which flows rather randomly into mainline
    today. That results in lack of review, push back and makes
    consolidation as hard as it gets.

    > If we add a new stage it will be difficult to follow for people

    What is difficult about that? How does it matter whether you ask A or
    B to pull and propagate your subarch code?

    > I'd like to have scenario example where such workflow will give a significant
    > advantage compare to the current workflow. And please real example.

    See above. It's not about examples, it's about solving issues like
    lack of review, lack of central places to do consolidation work and
    lack of push-back when stuff goes into the wrong direction.

    Thanks,

    tglx




    \
     
     \ /
      Last update: 2011-05-18 23:27    [W:4.147 / U:0.264 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site