Return-Path: X-Original-To: apmail-incubator-general-archive@www.apache.org Delivered-To: apmail-incubator-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3BC591020E for ; Sun, 25 Jan 2015 19:50:30 +0000 (UTC) Received: (qmail 75693 invoked by uid 500); 25 Jan 2015 19:50:29 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 75523 invoked by uid 500); 25 Jan 2015 19:50:29 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 75512 invoked by uid 99); 25 Jan 2015 19:50:29 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Jan 2015 19:50:29 +0000 Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id C4FE61A01E4 for ; Sun, 25 Jan 2015 19:50:28 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id f15so4785221lbj.0 for ; Sun, 25 Jan 2015 11:50:25 -0800 (PST) X-Received: by 10.152.27.130 with SMTP id t2mr17389306lag.28.1422215425558; Sun, 25 Jan 2015 11:50:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.11.207 with HTTP; Sun, 25 Jan 2015 11:49:43 -0800 (PST) In-Reply-To: <54C53FD8.5030901@apache.org> References: <54C53757.1010004@apache.org> <54C53FD8.5030901@apache.org> From: Andrew Purtell Date: Sun, 25 Jan 2015 11:49:43 -0800 Message-ID: Subject: Re: my pTLP view To: "general@incubator.apache.org" Content-Type: multipart/alternative; boundary=089e0160b6d03c13ff050d7f5580 --089e0160b6d03c13ff050d7f5580 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > This is *exactly* the way things work in a TLP. Yes, everyone new to the Foundation on the PPMC has a sense of equal ownership in the process. The PPMC makes a decision together as equals, then the decision is reviewed as a whole. But this is not how things would work in a pTLP, right? Individuals there would effectively cast votes +1 (binding), or -1 (binding), +1 (non-binding), or -1 (non-binding), etc., depending if they are a Member or not. Maybe in practice the pTLP PMC wouldn't write down their votes like that, but somehow the distinction must be presented in the tallies to be meaningful. On Sun, Jan 25, 2015 at 11:11 AM, Branko =C4=8Cibej wrot= e: > On 25.01.2015 19:51, Andrew Purtell wrote: > >> That hardly ever happens (it's most likely when there are problems wit= h > > =E2=80=8B> =E2=80=8B > > a podling's first few releases), which is why you get the impression > > =E2=80=8B> =E2=80=8B > > that the PPMC can make binding decisions. > > > > =E2=80=8BClose. The PPMC membership feels they have made a decision tha= t matters > > with equal input. > > Certainly on PPMCs I've been on, > > =E2=80=8Bthere is awareness that everything is > > provisional > > =E2=80=8B. Still, a > > process takes place on PPMC mailing lists leading to a tallied outcome= . > > The input that leads to this output is the consensus or voting of *a > group > > of equal peers*. > > =E2=80=8B This output is handed to the IPMC in aggregate. =E2=80=8B > > When casting votes on the PPMC lists there are no +1 (binding) or +1 > > (non-binding) distinctions made. PPMC sends the outcome over to the IPM= C > > feeling some level of ownership having just participated in a decision > > making process as equal > > =E2=80=8Bs=E2=80=8B > > . (Or at least so I think, in some perhaps quaint notion.) Of course in > > IPMC voting it is different, but the IPMC is where supervision happens, > or > > doesn't, as some argue. > > This is *exactly* the way things work in a TLP. Any committer can > propose a release. The PMC must (!) start a (public) vote. Anyone can > vote, with PMC votes being binding. /Any/ -1 vote, either from PMC > member or plain committer, should block the release and trigger a > discussion to find a solution; and in this discussion (which purpose is > to reach consensus on a solution), PMC members have no more voice than > any other community member. > > If the PMC decides to ignore a -1 on a release vote, they'd better have > really good reasons for that, or I'd expect the Board to come down like > a ton of bricks on that PMC. > > The situation is slightly different with new committer/PMC member > nominations and votes, which are private; you have a point there. > > -- Brane > > > On Sun, Jan 25, 2015 at 10:35 AM, Branko =C4=8Cibej = wrote: > > > >> On 25.01.2015 19:16, Andrew Purtell wrote: > >>> With a PPMC we invite newcomers to make votes we call binding on > matters > >> of > >>> their own project. > >> As other people have said, PPMC members (that are not also IPMC member= s) > >> do not have binding votes, neither for releases nor for inviting new > >> committers/PPMC members. The "binding" bit lies with the IPMC, which c= an > >> revoke any formal decision made by the PPMC. > >> > >> That hardly ever happens (it's most likely when there are problems wit= h > >> a podling's first few releases), which is why you get the impression > >> that the PPMC can make binding decisions. In this respect, there's no > >> practical difference between the current IPMC model and the proposed > >> pTLP model. > >> > >> Of course, when it comes to /technical/ decisions, there's no such thi= ng > >> as a vote, so the term "binding" does not apply. Consensus, of one for= m > >> or another, always rules: and the IPMC or mentors can't meddle in this > >> case. > >> > >> -- Brane > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org > >> For additional commands, e-mail: general-help@incubator.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org > For additional commands, e-mail: general-help@incubator.apache.org > > --=20 Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) --089e0160b6d03c13ff050d7f5580--