Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4C78110A65 for ; Wed, 26 Feb 2014 16:20:37 +0000 (UTC) Received: (qmail 67415 invoked by uid 500); 26 Feb 2014 16:20:36 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 67089 invoked by uid 500); 26 Feb 2014 16:20:35 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 67081 invoked by uid 99); 26 Feb 2014 16:20:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Feb 2014 16:20:35 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Abhinandan.Prateek@citrix.com designates 103.14.252.240 as permitted sender) Received: from [103.14.252.240] (HELO SMTP.CITRIX.COM.AU) (103.14.252.240) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Feb 2014 16:20:30 +0000 X-IronPort-AV: E=Sophos;i="4.97,548,1389744000"; d="scan'208";a="3162330" Received: from sinaccessns.citrite.net (HELO SINPEX01CL01.citrite.net) ([10.151.60.9]) by sinpip01.citrite.net with ESMTP; 26 Feb 2014 16:20:07 +0000 Received: from SINPEX01CL03.citrite.net ([169.254.3.214]) by SINPEX01CL01.citrite.net ([169.254.1.73]) with mapi id 14.02.0342.004; Thu, 27 Feb 2014 00:20:07 +0800 From: Abhinandan Prateek To: "dev@cloudstack.apache.org" Subject: Re: [DISCUSS] Policy blocker? Thread-Topic: [DISCUSS] Policy blocker? Thread-Index: AQHPLkEY2H2e8i/dikmyNVnY8bQtHJq9ob+AgAIzWYCAAAWDAIAACI2AgAAGwgCAAH2eAIAAB22AgAW9qICAAPM+gIAAdvGA Date: Wed, 26 Feb 2014 16:20:06 +0000 Message-ID: References: <53060741.9050600@widodh.nl> <643B7A20-6334-4B26-8FD8-2DBB6CE201EE@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.13.112.14] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-DLP: SIN1 X-Virus-Checked: Checked by ClamAV on apache.org +1 this is reasonable. On 26/02/14 8:14 pm, "Chip Childers" wrote: >On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi > wrote: >> >> Folks since the liability of Release manager has been called out >>explicitly for the release I want to call out that I cannot take >>personal liability for a release and I am not sure why would anyone else >>in Release Manager role will take up personal liability. I don't see >>anything called out in our bylaws that states Release Manager being >>liable. >> >> That being said I am seeking advice from ASF mentors and will discuss >>it in PMC. I will proceed and build an RC after this issue is resolved. >> >> Thanks >> Animesh > >A couple of things: > >First, we don't have any "mentors" anymore... we're a TLP. > >Second, although the question of "liability" has been clarified in the >private@ thread, I'll summarize briefly here: > >The reason that we follow the voting process (where the PMC votes are >binding) and other ASF-wide policies, is so that any release is an >"act of the foundation" and not an act of an individual. The point is >that if someone were to purposefully ignore policy, then they put >themselves at risk. The whole reason for the foundation to have it's >policies is to protect all of the committers and contributors from >personal liability! So the only thing that really matters is that if >we follow the policies of the foundation, there's nothing to worry >about. > >Being a release manager is nothing to worry about... the whole PMC is >helping to ensure that we follow policies. As our current 4.3 issue >has pointed out, sometimes this means we have to slow down to fix >something. If something slipped through, it's still not a "liability" >issue in practical terms. It's just a mistake that we would then work >to correct. > >Make sense? > >-chip