From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 40DBB1381F3 for ; Mon, 21 Oct 2013 10:48:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4AC6FE0C5F; Mon, 21 Oct 2013 10:48:10 +0000 (UTC) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4F97FE0C0E for ; Mon, 21 Oct 2013 10:48:09 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id to1so14856585ieb.37 for ; Mon, 21 Oct 2013 03:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=L+us4VBJtX4cMsJeZb8FoyP6AyQVvmSxFCWN977hrkQ=; b=KLdxbh6UE1UELbBm95i1WZz/OOkzgKdewkLMvD3EcNrli99f7CS3p8QmJA0yNqVXYA 8vFrdpT0h36GhXIu8zQj8Q1uY5JbT/p9kAYT6NY5RVkcE4aTg6fiYBFwKw52/hbiW/it Oz4/b597mFuxX/WanOKAzdZzULwdIVCGWo57CRoLKw64PqY6XLSU3BkMTiXzh/+Ygsbx cGVDfsOkJWx5oPuqtK7QhJwY/eB3CBBMqllxVsbWToPjRGfejDxZhqiBbOPw2/bApINW zU+aTYln1URISazWfsQMuziheMtpC/fraQqNfoG4IKbo0Xd9VQpCLr31eSEyd9cNyY5P SsFA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.154.66 with SMTP id vm2mr8688111igb.57.1382352488405; Mon, 21 Oct 2013 03:48:08 -0700 (PDT) Received: by 10.50.158.163 with HTTP; Mon, 21 Oct 2013 03:48:08 -0700 (PDT) In-Reply-To: <52650175.7070106@libertytrek.org> References: <52629F15.1050803@sporkbox.us> <5263174E.8000004@googlemail.com> <5263795D.2070503@sporkbox.us> <5263A157.4070001@googlemail.com> <5263B5F3.9020604@sporkbox.us> <5263EBD8.2010400@libertytrek.org> <5264FA0F.8070802@libertytrek.org> <52650175.7070106@libertytrek.org> Date: Mon, 21 Oct 2013 18:48:08 +0800 Message-ID: Subject: Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager? From: Mark David Dumlao To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 2c9c5d13-c024-4ed4-9090-d1e21f5de8b1 X-Archives-Hash: 4ba55ad8646a7c235ec8797187624e75 On Mon, Oct 21, 2013 at 6:27 PM, Tanstaafl wrote: > On 2013-10-21 6:11 AM, Mark David Dumlao 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