| 1 |
On Mon, Oct 21, 2013 at 6:27 PM, Tanstaafl <tanstaafl@×××××××××××.org> wrote: |
| 2 |
> On 2013-10-21 6:11 AM, Mark David Dumlao <madumlao@×××××.com> wrote: |
| 3 |
>> |
| 4 |
>> I doubt he actually has the time to read every line of code submitted |
| 5 |
>> to the kernel, |
| 6 |
> |
| 7 |
> |
| 8 |
> That isn't what I meant at all... |
| 9 |
> |
| 10 |
> What he *does* have the power to do, though, is if someone was able to sneak |
| 11 |
> in something outrageously bad that caused breakage, he would rip it out at |
| 12 |
> its roots, and probably make sure that whoever was responsible for it |
| 13 |
> getting in was either properly chastised (if it was unintentional), or |
| 14 |
> |
| 15 |
|
| 16 |
Again. This power is overstated and overtrusted. As for "rip it out at |
| 17 |
its roots" he has no ability to do that, only refuse to merge it in |
| 18 |
his tree. But that's only if he bothers to read it. With all the other |
| 19 |
stuff he's working on, he signs off less commits than all the other |
| 20 |
maintainers do. |
| 21 |
|
| 22 |
The news sites love making a big deal of him flaming this or that |
| 23 |
developer or company, but I can't remember that ever stopping anyone |
| 24 |
from doing what they wanted. |
| 25 |
|
| 26 |
> |
| 27 |
>> tldr: if the maintainer of some subsystem agrees, it's probably in. It |
| 28 |
>> takes a lot of trust to get to become a maintainer. |
| 29 |
> |
| 30 |
> |
| 31 |
> that trust would be lost, maybe for good. |
| 32 |
> |
| 33 |
> And by the way, it is this trust that you speak of that is one of the main |
| 34 |
> reasons why I'm not worried about this. Linus has good people around him, |
| 35 |
> and none of them would allow something like it to happen either. |
| 36 |
> |
| 37 |
|
| 38 |
I'm just explaining your overstatement of "trust" and I don't know |
| 39 |
what this "something like this" is referring to. Obviously "broken |
| 40 |
changes" isn't something to commit and is embarassing. But if you're |
| 41 |
talking about Lennart-FUD, I will point you to |
| 42 |
/usr/src/linux/doc/ManagementStyle |
| 43 |
|
| 44 |
""" |
| 45 |
Btw, another way to avoid a decision is to plaintively just whine "can't |
| 46 |
we just do both?" and look pitiful. Trust me, it works. If it's not |
| 47 |
clear which approach is better, they'll eventually figure it out. The |
| 48 |
answer may end up being that both teams get so frustrated by the |
| 49 |
situation that they just give up. |
| 50 |
""" |
| 51 |
|
| 52 |
That's kind of the official kernel stance on "future of kernel |
| 53 |
development" bla bla bla. If it's maintainable, they merge it, because |
| 54 |
you can't really tell if one approach is going to "win" until it later |
| 55 |
does. |
| 56 |
|
| 57 |
-- |
| 58 |
This email is: [ ] actionable [ ] fyi [ ] social |
| 59 |
Response needed: [ ] yes [ ] up to you [ ] no |
| 60 |
Time-sensitive: [ ] immediate [ ] soon [ ] none |
Archives