[PATCH] MAINTAINERS: extend Raspberry Pi entry
Michael Zoran
mzoran at crowfest.net
Sun Jan 29 14:02:04 PST 2017
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...
More information about the linux-rpi-kernel
mailing list