All of lore.kernel.org
 help / color / mirror / Atom feed
From: mzoran@crowfest.net (Michael Zoran)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] MAINTAINERS: extend Raspberry Pi entry
Date: Sun, 29 Jan 2017 14:02:04 -0800	[thread overview]
Message-ID: <1485727324.30797.7.camel@crowfest.net> (raw)
In-Reply-To: <20170129215253.hwhwsqoulhmjxs55@tarshish>

On Sun, 2017-01-29 at 23:52 +0200, Baruch Siach wrote:
> On Sun, Jan 29, 2017 at 01:41:49PM -0800, Michael Zoran wrote:
> > On Sun, 2017-01-29 at 23:06 +0200, Baruch Siach wrote:
> > > Kernel development is email based. See "Why kernel development
> > > still
> > > uses? email"[1]. What would you like to see improved?
> > 
> > No offense to any of the maintainers, but the e-mail system is
> > optimized for a very large number of very, very small changes. It
> > isn't
> > optimized for large changes.? In a way it tends to discourage any
> > kind
> > of big improvements.
> > 
> > The idea of checking in a very large number of small patches makes
> > sense for auditing.? And yes having both isn't totally possible, so
> > I
> > don't know really where the line should go between the two.? But
> > taking
> > things to one extreme or the other doesn't make sense either.
> 
> In extreme cases like the examples below sending email patches
> doesn't make?
> sense, so direct git pulls can be used instead. But these cases are
> quite?
> rare.
> 
> Commit 07a8c03f3e0 (ARM: reduce defconfigs) shortstat is:
> 
> ?177 files changed, 652 insertions(+), 194157 deletions(-)
> 
> Commit 607ca46e97 (UAPI: (Scripted) Disintegrate include/linux)
> shortstat is:
> 
> ?578 files changed, 32659 insertions(+), 30108 deletions(-)

Pulls make sense, but perhaps a concept of a pull that only allows a
subtree to be modified makes sense.

Perhaps you have some idiot that doesn't know what they are doing.  If
you confine their changes to a certain directory, in theory it would
limit that amount of damage that could be done(to a certain extent).

At the very minimum, I would think that hardware specific drivers
should be handled differently then core drivers or non-platform
specific drivers.

I mean really, why should the vendor of the RPI have to deal with a
gazillion requests to change the default built configuration.

But then again, having everything in one tree makes it easy to make
sure everything can be rebuilt from a clean build...


  

  reply	other threads:[~2017-01-29 22:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-29 20:08 [PATCH] MAINTAINERS: extend Raspberry Pi entry Baruch Siach
2017-01-29 20:52 ` Michael Zoran
2017-01-29 21:06   ` Baruch Siach
2017-01-29 21:41     ` Michael Zoran
2017-01-29 21:52       ` Baruch Siach
2017-01-29 22:02         ` Michael Zoran [this message]
2017-01-29 22:24           ` Michael Zoran
2017-01-30  7:56             ` Uwe Kleine-König
2017-01-30  8:09               ` Michael Zoran
2017-01-30  8:51                 ` Uwe Kleine-König
2017-01-30  9:01                   ` Michael Zoran
2017-01-29 21:06   ` Stefan Wahren
2017-01-29 21:25   ` Michael Zoran
2017-01-30 17:03 ` Stephen Warren
2017-01-31 19:49   ` Eric Anholt
2017-02-01  5:21     ` Stephen Warren
2017-02-01 19:51       ` Eric Anholt

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=1485727324.30797.7.camel@crowfest.net \
    --to=mzoran@crowfest.net \
    --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.