mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <greg@kroah.com>,
	ksummit-2012-discuss@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-2012-discuss] [ATTEND or not ATTEND] That's the question!
Date: Sun, 17 Jun 2012 18:04:43 +0100	[thread overview]
Message-ID: <20120617170442.GA10241@sirena.org.uk> (raw)
In-Reply-To: <20120616123032.251dd101@pyramind.ukuu.org.uk>

On Sat, Jun 16, 2012 at 12:30:32PM +0100, Alan Cox wrote:
> Greg KH <greg@kroah.com> wrote:

> We also have a large consumer electronics and now android ecosystem much
> of which is made up of companies and people whose business history and
> business model for all products has always been

> - make it boot
> - make it usable
> - ship it
> - run 

> they have little incentive to share, they have no interest in the longer
> term, and it's often not rational economics for them to clean up their
> code and upstream it because it just helps their rivals, and besides the
> part is now 6 months old so obsolete in their world.

This is actually getting a lot better these days.

> For a lot of hardware the only way that is going to get fixed is if

> a) it is easier to do the job right than hack it up
> b) when the hardware vendors are more involved and have longer term plans
> c) their customers start to demand it in order to be up and running very
> fast (ie there is heavy consolidation in the platform)

The latter two are happening right now, mostly thanks to consumer demand
for software updates for things like phones though the desire to keep
hardware platforms rolling indepenently of OS releases is also a factor.
One of the big blockers to that has been the need to move all the out of
tree stuff up to a newer kernel, reducing the diff to mainline is a good
way to minimise the effort involved.  I was very pleased when I started
to find handset vendors wanting to confirm that patches given to them
were also going upstream.

This doesn't apply to all hardware but more and more things are getting
in field updates.

> Right now we are doing it for real in some areas, and via the "screw
> this, mail Andrew Morton" process for others, plus Linus fields some of
> the really dumb ones. We could formalise some of that a bit more and
> encourage more maintainers to actual team up with one of the other
> contributors they trust.

Yes, this would really help as would better backup plans when things
aren't working.  Finding people to work with is not just a question of
trust, it's also a question of finding people with similar work patterns
as a mismatch can be painful.

  parent reply	other threads:[~2012-06-17 17:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15 22:56 Thomas Gleixner
2012-06-15 23:34 ` [Ksummit-2012-discuss] " Greg KH
2012-06-16 10:50   ` Thomas Gleixner
2012-06-16 13:29     ` Jonathan Corbet
2012-06-16 13:32       ` Frederic Weisbecker
2012-06-16 13:56       ` Rafael J. Wysocki
2012-06-17 10:40       ` Thomas Gleixner
2012-06-17 18:51         ` Greg KH
2012-06-17 18:58       ` Mark Brown
2012-06-20 19:51       ` J. Bruce Fields
2012-07-06  9:43         ` Glauber Costa
2012-07-06  9:54           ` Frederic Weisbecker
2012-07-06  9:59             ` Glauber Costa
2012-07-06 10:00             ` Srivatsa S. Bhat
2012-07-06 10:03               ` Glauber Costa
2012-07-06 10:21                 ` Srivatsa S. Bhat
2012-07-06 10:11             ` Richard Cochran
2012-07-06 10:14               ` Glauber Costa
2012-07-06 10:36               ` Srivatsa S. Bhat
2012-07-06 10:43                 ` Glauber Costa
2012-07-06 12:42                   ` Steven Rostedt
2012-07-17 22:17           ` david
2012-06-16 11:30   ` Alan Cox
2012-06-16 15:03     ` Phil Turmel
2012-06-16 16:43     ` Myklebust, Trond
2012-06-20  0:40       ` Dave Chinner
2012-06-17 17:04     ` Mark Brown [this message]
2012-06-19 15:45 ` Bjorn Helgaas
2012-06-19 19:18   ` Roland Dreier

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=20120617170442.GA10241@sirena.org.uk \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=ksummit-2012-discuss@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®