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