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 4B1E2100EB for ; Sat, 22 Feb 2014 08:07:43 +0000 (UTC) Received: (qmail 59768 invoked by uid 500); 22 Feb 2014 08:07:42 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 59249 invoked by uid 500); 22 Feb 2014 08:07:38 -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 59241 invoked by uid 99); 22 Feb 2014 08:07:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 22 Feb 2014 08:07:36 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of runseb@gmail.com designates 209.85.215.180 as permitted sender) Received: from [209.85.215.180] (HELO mail-ea0-f180.google.com) (209.85.215.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 22 Feb 2014 08:07:31 +0000 Received: by mail-ea0-f180.google.com with SMTP id o10so1992393eaj.11 for ; Sat, 22 Feb 2014 00:07:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=0kMiSq3zCZmVs3Q5TRUyrjsuu0OSEgPyjX7l/Sc2UQw=; b=unpk1NfhcWL3Qsg1PODGMl4+onzJpM+AosbQpThfY5YuyOxI5Wl28J1+DXJlWT+X/e fXXmH3H0IrP/5HUXwEA2aHHM+AS6eutUFiUpu+T95ECF7SpquwC8ZxInP6CTP1HMXjB8 L91gZP7h6hPXQDv7+/PPot0n0BaPDoNVmBoB1G0g/3eS0Y2lIzOPTEez+6dDcRLsn86P KzXblkRW3d4IClTgoqxuDi90Aing4qIFEwGZOheHChjw6X5kw00JM+1dd1+OFgbWnlmD TmNtVP3rkgi8VuLbaYjfzQ53fT7qN+Hsgoa3y1IcPWN9sV6CBWopePp3WNtVOpcVnSBx ZgzA== X-Received: by 10.14.223.9 with SMTP id u9mr12702898eep.79.1393056429649; Sat, 22 Feb 2014 00:07:09 -0800 (PST) Received: from [10.0.0.5] (129-249.193-178.cust.bluewin.ch. [178.193.249.129]) by mx.google.com with ESMTPSA id m1sm35938070een.7.2014.02.22.00.07.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Feb 2014 00:07:08 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [DISCUSS] Policy blocker? From: Sebastien Goasguen In-Reply-To: Date: Sat, 22 Feb 2014 03:07:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <643B7A20-6334-4B26-8FD8-2DBB6CE201EE@gmail.com> References: <53060741.9050600@widodh.nl> To: dev@cloudstack.apache.org X-Mailer: Apple Mail (2.1510) X-Virus-Checked: Checked by ClamAV on apache.org On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi = wrote: >=20 >=20 >> -----Original Message----- >> From: David Nalley [mailto:david@gnsa.us] >> Sent: Friday, February 21, 2014 4:13 PM >> To: dev@cloudstack.apache.org >> Subject: Re: [DISCUSS] Policy blocker? >>=20 >>>> LEGAL - when I talk about legal problems below I refer to liability >>>> incurred by individuals in the project, especially the release >>>> manager, >>>=20 >>> [Animesh] Can you clarify 'especially the release manager' part? = Release >> manager is just like any other volunteer and does not have any = special >> privileges. The community VOTEs on the release. >>>=20 >>=20 >> Sure, it isn't about privilege, it's about liability. So the = foundation covers >> (and has insurance for) actions taken on behalf of the Foundation. If = process >> is followed (including getting the votes) releasing software is = effectively a >> function of the Foundation - and thus it bears liability. The = foundation >> needs to ensure that the release is a 'authorized business decision' = on behalf >> of the Foundation (which is why the Board has to ACK PMC additions, = etc.). >> Hence all the process and policy. >>=20 >> Publishing software however, if really done by the release manager. >> And if release process isn't followed, it's no longer a function of = the >> foundation - and software is effectively released by the RM, and thus = he is >> individually liable.=20 > [Animesh] How do you define the release process being followed or not? = Isn't Voting on a release the process and PMC and everyone voting = responsible for it. Release Manager is a facilitator. Without the = protection why would anyone want to incur liability as a release = manager? In the links that you sent I have not seen specific reference = to Release Manager being liable.=20 >=20 > Sadly this isn't theoretical, and is one of the reasons that >> the foundation exists. > [Animesh] What does foundation provide in that case? >>=20 I read David note as saying that if we follow the release process = properly -calling for votes, respecting bylaws timeframe, tallying=85etc- = then the ASF is liable for what's in the release. But if we were to not = follow due process then the RM would be liable. In our case we follow process, so the Foundation is liable. >> http://www.apache.org/dev/release.html#why >> https://www.apache.org/foundation/faq.html#why >>=20 >> --David