All of lore.kernel.org
 help / color / mirror / Atom feed
From: grinberg@compulab.co.il (Igor Grinberg)
To: linux-arm-kernel@lists.infradead.org
Subject: Update: ARM Sub-Architecture Maintainers workshop at Kernel Summit 2011
Date: Mon, 17 Oct 2011 19:31:13 +0200	[thread overview]
Message-ID: <4E9C6661.70402@compulab.co.il> (raw)
In-Reply-To: <alpine.LFD.2.02.1110121103090.17040@xanadu.home>

On 10/12/11 17:33, Nicolas Pitre wrote:
> On Wed, 12 Oct 2011, Igor Grinberg wrote:
> 
>> On 09/27/11 16:25, Igor Grinberg wrote:
>>> On 08/30/11 09:00, Grant Likely wrote:
>>>> Still accepting more proposals.  Send me the topics you are burning to discuss.
>>>
>>> One of the LPC2011's bottom lines was:
>>> "We need more people involved in ARM maintainership to help
>>> the sub-architecture maintainers do a better job on
>>> review/consolidation/generalization/etc. of the code."
>>>
>>> Despite the major goal of the DT to reduce the SoC and
>>> board specific code to absolute minimum, there will still be cases
>>> (e.g. discrete power management circuitry) when there is no
>>> appropriate DT solution available and the board file
>>> is a necessity. Also there are already many boards that will remain
>>> and will not be converted to DT.
>>>
>>> Bringing all the above together, I'd like to propose a new "job"
>>> for maintaining board specific code on a cross-platform basis.
>>>
>>> Pros:
>>> 1) There might (I have not checked this, but I'm sure there is) be
>>> code in the existing board files (that are not likely to go away
>>> at least in a couple of years) that can be consolidated and
>>> may be even in a cross-platform manner.
>>> 2) Lower the work load from SoC maintainers (that don't have enough
>>> time to care much about the board specific changes).
>>> 3) Some more eyes to review the newly submitted code.
>>>
>>> Cons:
>>> 1) Resulting overhead for the code to go upstream.
>>> 2) Possible addition of merge conflicts.
>>>
>>>
>>> I'd like to hear, what do you think of the above proposal?
>>
>> Any thoughts? Yes? No? Why? WTF?
> 
> Well...  Please see http://lwn.net/Articles/443510/.
> 
> Since then,  ARnd Bergmann has led the arm-soc repository maintenance 
> effort as you might have noticed.  Other cleanup/consolidation projects 
> are also progressing in parallel.

Yes, of course I've noticed (how can someone to not notice?).

> 
> Obviously, as always, we would always benefit from more reviewers and 
> more people in maintainership roles.  The general situation has improved 
> since a couple months ago, but any additional suggestions you might have 
> will always be welcome.

Yes, the situation did improve, that is correct.

Currently, SoC maintainers have a separate branch of board specific
patches and it is kind of a burden that they live with and push it
to Arnd.
What I'm trying to propose here is another level of maintainership.
Which would accumulate board specific stuff (not SoC specific) and
push it to Arnd directly with no need to involve SoC maintainers
(may be only for Acks on SoC stuff).
Despite all the efforts to move to DT, there is still much work
must be done and IMO the board files aren't going to disappear in
the near future (say 2 years?). Meanwhile, my proposition can
lower the work load from SoC maintainers.

There is a possibility that my proposal will not serve well,
or may be it will?

Before making any decision, I want to make sure you understand
what is that I'm proposing here.

-- 
Regards,
Igor.

  reply	other threads:[~2011-10-17 17:31 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-30  6:00 Update: ARM Sub-Architecture Maintainers workshop at Kernel Summit 2011 Grant Likely
2011-08-30  6:27 ` Igor Grinberg
2011-08-30 13:44   ` Grant Likely
2011-08-30 14:00     ` Igor Grinberg
2011-08-30 19:17     ` [Ksummit-2011-discuss] " Chris Ball
2011-08-30 12:55 ` Nicolas Ferre
2011-08-30 13:56 ` Wolfram Sang
2011-08-30 14:42 ` David Brown
2011-08-30 16:58 ` Paul Walmsley
2011-08-30 19:51 ` Olof Johansson
2011-08-30 23:42   ` Stephen Warren
2011-08-31  5:50   ` Marek Szyprowski
2011-08-30 23:10 ` Pavel Machek
2011-08-31  1:29   ` Marek Vasut
2011-08-31  2:31     ` Bryan Wu
2011-08-31  2:58       ` Marek Vasut
2011-08-31  3:07         ` Bryan Wu
2011-08-31 18:57     ` Grant Likely
2011-08-31  2:57 ` Bryan Wu
2011-08-31  2:59   ` Marek Vasut
2011-08-31  3:08     ` Bryan Wu
2011-08-31  4:01       ` Marek Vasut
2011-08-31  5:52         ` Eric Miao
2011-08-31 15:15 ` Marc Zyngier
2011-09-27 13:25 ` Igor Grinberg
2011-10-12  9:14   ` Igor Grinberg
2011-10-12  9:19     ` Catalin Marinas
2011-10-17 17:36       ` Igor Grinberg
2011-10-12 15:33     ` Nicolas Pitre
2011-10-17 17:31       ` Igor Grinberg [this message]
2011-10-12 10:01 ` Catalin Marinas
2011-10-12 15:00   ` Nicolas Pitre
2011-10-17  8:54 ` Catalin Marinas
2011-10-17 10:56   ` Marek Vasut
2011-10-20 13:35 ` Linus Walleij
2011-10-20 13:48   ` Jonathan Cameron
2011-10-20 14:25     ` Barry Song
2011-10-20 14:46       ` Mark Brown
2011-10-20 14:55         ` Jonathan Cameron
2011-10-21  9:39           ` Barry Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E9C6661.70402@compulab.co.il \
    --to=grinberg@compulab.co.il \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.