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:24:08 -0800 [thread overview]
Message-ID: <1485728648.30797.9.camel@crowfest.net> (raw)
In-Reply-To: <1485727324.30797.7.camel@crowfest.net>
On Sun, 2017-01-29 at 14:02 -0800, Michael Zoran wrote:
> 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
Basically, what I'm thinking is this:
Have a bcm283x module that is somehow changed locally and tested
locally, but the whole module gets published to the larger tree as a
snapshot. Anybody that normally submits changes to bcm283x can change
any file. I wouldn't take things to the extreme of having an owner of
the i2c module and another owner of the SPI module. The modules should
be reasonably large.
If it's better to have binary drops or source code drops I'm not sure.
Source drops with some change history makes more sense to me.
As for the signed off part or requiring multiple signed off bys, that
seems broken to me. The idea of having multiple people approve of
every single change is awesome. But at the same time it needs to be
built into the software revision control system. I mean, I e-mail a
patch or change with my name. I really don't have any idea, control,
or verification that the change I e-mail is actually the change that is
getting applied with my name on it.
next prev parent reply other threads:[~2017-01-29 22:24 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
2017-01-29 22:24 ` Michael Zoran [this message]
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=1485728648.30797.9.camel@crowfest.net \
--to=mzoran@crowfest$(echo .)net \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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