Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8524356imu; Thu, 15 Nov 2018 13:02:28 -0800 (PST) X-Google-Smtp-Source: AJdET5eU4RHiga3ffbcSk166dW6MtAcJecF/Nio9lOJ0bCnNu/V6La/XQuu2sxctDPQ45MK2rg3F X-Received: by 2002:a63:2ac9:: with SMTP id q192mr2370278pgq.58.1542315748801; Thu, 15 Nov 2018 13:02:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542315748; cv=none; d=google.com; s=arc-20160816; b=O4VobA81joxEvDEa3fTevFHXk/U9jqng2VnfKHUwk1oRvYF9Kx6e+OCo15XU6dHo5S fHS543oM8dV34WGrGSubFwBRjcSdVIpRiDchn2urlp1KXCLchSGmgGF1K2Du/mruTgFr Mu7p2UsTuO2xqa6ql7FvIbL1OixDLHeyB1gT7Iypf63GD49IoTO50jOTn+Ww+Bgf+Nny Buo9JWYueDcF5fPlW5/9ELN87nVqb2PsOpAgFwTl5jDIl+iS0ht7vvWwILCddh4q0D0b yCZP8PRvWgJHGdGiq4Nmg+Oeb0bT1cbRZxuonhbMtXMy/TQUDsBzSOuNAjL2u1DQ6wRh L2Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:openpgp:from:references:to:subject; bh=xp2ona9E8uIkAWkzQq/Qm1Usibdrg/gG0CvEePIelmg=; b=UBK9tjSQkhFQwq3g+UfLnQ3Z4/iuAwx6Xs7ivIpycehXdp8DMTgCqhHpXFHx91QuWS fUnrA0uMTaQ6Q1wmDqjMNxXrIyA+SSvq1yZDBkIXLgo65/4Hmta6Zj5iT1XTOzGrBVzr 8KzW+cOnRN7qNO9MefqXPMaTKGVihRG3q9v+VnP3CVhlAiNLl/P5+lFSPGD0dcROEt8m fAXt6SWqFSNgbSGUdao/QSo9alICht1oR8u0AnB17Mz3hdx14UWhXMlYbh96hs/fYO3w IFSCc2/iaIU93IpYaQJcN8ow2cciuIdxUDSau2z5MXdzdBnKimicYhzRvumBwMWPkipY oJlw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h6si11623270plk.231.2018.11.15.13.02.13; Thu, 15 Nov 2018 13:02:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726808AbeKPHJn (ORCPT + 99 others); Fri, 16 Nov 2018 02:09:43 -0500 Received: from mail-qk1-f196.google.com ([209.85.222.196]:45655 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725860AbeKPHJn (ORCPT ); Fri, 16 Nov 2018 02:09:43 -0500 Received: by mail-qk1-f196.google.com with SMTP id d135so34057019qkc.12 for ; Thu, 15 Nov 2018 13:00:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=xp2ona9E8uIkAWkzQq/Qm1Usibdrg/gG0CvEePIelmg=; b=Ay+Sed2JGTySJgaaWpx60N0fiPsZIDjPZ4+SXyMNcPPDeoYFM2l3SeqrxBCs7n6wYX yoPO/lisFgpYK0DYbBMufWZacZvNCPQfLtN9KAdmTyNvK9WUwuuso61xJ8rgx0zbPSak t9MOkiLH2lVszQ1VoFbz8MUbv+qhwRV53Wvea7VQZYKKo8S+xFauR130RqTapj1SqVQC 45RHw8m7A5nPo/EJyfmKcTw503FA/tUA2i9zk4MGscstewrO43KUhJAQAxrrfrWWl4eA fwXunwXjrre34C77ytvM0aVbq22VzMQvSN//aMQP76VzK9fFEGYBAqvQz0fPN/zaI7Jc 2oiw== X-Gm-Message-State: AGRZ1gJPUCKoC7AFrUBoKp7CDMML2kjdyi0dQuGSjsczZKb/xl3d+jaY 2aZbNKTmjxLInil7onExknwTOQ== X-Received: by 2002:a37:10cf:: with SMTP id 76mr7372175qkq.99.1542315616135; Thu, 15 Nov 2018 13:00:16 -0800 (PST) Received: from [10.150.73.190] (161.sub-174-227-144.myvzw.com. [174.227.144.161]) by smtp.gmail.com with ESMTPSA id l30sm6947604qte.44.2018.11.15.13.00.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 13:00:15 -0800 (PST) Subject: Re: Official Linux system wrapper library? To: "Theodore Y. Ts'o" , Joseph Myers , Daniel Colascione , Szabolcs Nagy , Dave P Martin , nd , Florian Weimer , "Michael Kerrisk (man-pages)" , linux-kernel , Joel Fernandes , Linux API , Willy Tarreau , Vlastimil Babka , "libc-alpha@sourceware.org" References: <875zx2vhpd.fsf@oldenburg.str.redhat.com> <20181113193859.GJ3505@e103592.cambridge.arm.com> <5853c297-9d84-86e5-dede-aa2957562c6b@arm.com> <20181115053026.GA20617@thunk.org> <20181115170807.GB20617@thunk.org> From: Carlos O'Donell Openpgp: preference=signencrypt Organization: Red Hat Message-ID: <48868f73-53b4-a01a-de73-4a7b56b91c60@redhat.com> Date: Thu, 15 Nov 2018 16:00:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181115170807.GB20617@thunk.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/15/18 12:08 PM, Theodore Y. Ts'o wrote: > On Thu, Nov 15, 2018 at 04:29:43PM +0000, Joseph Myers wrote: >> On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote: >> >>> That's great. But is it or is it not true (either de jure or de >>> facto) that "a single active glibc developer" can block a system call >>> from being supported by glibc by objecting? And if not, under what is >>> the process by resolving a conflict? >> >> We use a consensus-building process as described at >> . > > So can a single glibc developer can block Consensus? Yes. I think the comparison to the "liberum veto" is not a fair comparison to the way the glibc community works :-) (1) Community consensus. Consensus need not imply unanimity. Consensus is only from the set of important and concerned interests. The community gets to decide that you're a troll that does no real work, and can therefore ignore you. Consensus is blocked only by sustained objection (not just normal objections, which are recorded as part of the development process e.g. "I don't like it, but I leave it up to you to decide"). Therefore an involved glibc developer can lodge a sustained objection, and block consensus. (2) The GNU package maintainers for glibc. There are 8 GNU package maintainers for glibc. The package maintainers created the consensus process to empower the community, but they can act as a final review committee to move issues where there are two reasonable but competing view points. As Joseph points out we haven't ever used the GNU pakcage maintainers to vote on a stuck issue, but I will arrange it when the need arises. If you think we're at that point with wrapper functions, just say so, but it doesn't seem like it to me. -- Cheers, Carlos.