Return-Path: X-Original-To: apmail-legal-discuss-archive@www.apache.org Delivered-To: apmail-legal-discuss-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 39F7610A26 for ; Thu, 29 May 2014 14:55:57 +0000 (UTC) Received: (qmail 82962 invoked by uid 500); 29 May 2014 14:55:57 -0000 Delivered-To: apmail-legal-discuss-archive@apache.org Received: (qmail 82804 invoked by uid 500); 29 May 2014 14:55:56 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 82797 invoked by uid 99); 29 May 2014 14:55:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 May 2014 14:55:56 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of stephen.alan.connolly@gmail.com designates 74.125.82.171 as permitted sender) Received: from [74.125.82.171] (HELO mail-we0-f171.google.com) (74.125.82.171) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 May 2014 14:55:53 +0000 Received: by mail-we0-f171.google.com with SMTP id w62so543633wes.30 for ; Thu, 29 May 2014 07:55:32 -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=vvqzHRKemnazQmX9eoLeSBf+hz2MHOIB88nUFvbQuiY=; b=HsKvwG+RSxBcWbarai4rt2d52Dvynh+8aoXvdj9PfGQy2pL2lZU8iyn49tv8eyPc9V URwRXfZ9OynQdtbuzK2EOxj6iVq8zUp6wFXoM8PH2aytXlrkuy/xpwial+Vzv/vOrO9T IbEjcMwGf6fhCTb6Du9DJfx2pUdRYqUfjWH8F4Ubh24CUC+gnfSG8U7WNsrhVbVpzG67 eSCCJB6A5Mw4/KkEJWoqSphrYOfsiiQZNRdifdtRN8Y/WUV9wvA9iWGH2cdH8YZpeOgU jZ/TF4S3kPAaufZ0DtBoN9xhHmJuUggBByHVFKWdr/EOM4PsrP6HXaGsDITRSXC+ejv7 jFUA== MIME-Version: 1.0 X-Received: by 10.180.77.70 with SMTP id q6mr60127598wiw.28.1401375331849; Thu, 29 May 2014 07:55:31 -0700 (PDT) Received: by 10.194.205.233 with HTTP; Thu, 29 May 2014 07:55:31 -0700 (PDT) In-Reply-To: References: <73754EE1-6D35-44E9-BB57-B3B3D7DCC65D@jaguNET.com> <1401365699.71123.YahooMailBasic@web28906.mail.ir2.yahoo.com> Date: Thu, 29 May 2014 15:55:31 +0100 Message-ID: Subject: Re: Clarification about D&O insurance and bad acts From: Stephen Connolly To: "legal-discuss@apache.org" Content-Type: multipart/alternative; boundary=f46d043be038da1ee104fa8b1e49 X-Virus-Checked: Checked by ClamAV on apache.org --f46d043be038da1ee104fa8b1e49 Content-Type: text/plain; charset=UTF-8 On 29 May 2014 15:54, Stephen Connolly wrote: > Actually I like the QA analogy ;-) > > And a QA department is not going to check every toy in every batch of > toys.... instead they will do a random check... either checking one toy at > random in each batch (or a fraction of batches), or checking all toys in a > small fraction of batches. > Oh! and if they find a failure then they will obviously call halt and start checking more... and only reduce the level of checks once things return to normal. > > So following the QA analogy, if each PMC member does some random > spot-checks as a QA assurance that the required buts are present... would > that be OK? > > > On 29 May 2014 13:14, Mark Struberg wrote: > >> +1 >> >> Think about it like a QA department of a production line in a company >> building children toys. >> >> Of course all employees take care to not introduce a failure which might >> harm children. But even then it _might_ happen. >> >> Now what would happen if such a failure really appears? They would sue >> the hell out of this company... >> >> By having a QA department which does an independent check if all is fine >> over and over again this risk might get reduced. And even if a failure >> still slips through it will help the company to not get hit too hard at >> least. >> >> LieGrue, >> strub >> >> -------------------------------------------- >> On Thu, 29/5/14, Jim Jagielski wrote: >> >> Subject: Re: Clarification about D&O insurance and bad acts >> To: legal-discuss@apache.org >> Date: Thursday, 29 May, 2014, 13:49 >> >> Not sure what you mean by >> that... One of the aspects >> of verifying a >> release is checking that the bits going out >> are, in fact, the expected and correct bits... >> which sounds >> like src verification to me. >> And is, obviously, appropriate >> and >> necessary. >> >> On May 28, 2014, >> at 2:47 PM, Brian LeRoux wrote: >> >> > Agreed! That said, src >> verification for releases is not always appropriate or >> necessary. (Depending on the project, the people and their >> unique attributes.) >> > >> > On May 28, 2014 1:01 PM, "Jim >> Jagielski" >> wrote: >> > That is true. But doing normal >> work-in-progress, and the >> > oversight >> thereof, is a different thing than doing a >> > release. >> > >> > One does not negate the other, nor does it >> remove the >> > need for the other. Saying >> "we do X oversight for our day >> > to >> day development" does not mean that no oversight is >> > needed for a release, simply because >> it's a different >> > kind of oversight >> for a different kind of activity. >> > >> > On May 27, 2014, at 5:22 PM, Brian LeRoux >> wrote: >> > >> > > We could both >> wax hypothetical about the merit of humans and error >> proneness. My point is whatever is work-in-progress is a >> daily responsibility and not something to be left for the >> last minute check by others. Ever. >> > >> > >> > > >> > > On >> Tue, May 27, 2014 at 2:59 PM, Ross Gardler >> wrote: >> > > Brian, you are absolutely >> correct. However, SVN is not the release and so having >> reviewed commits is not the same as having reviewed the >> release. In a well run project where people are reviewing >> code commits there should be no problem. But people make >> errors and you would be surprised how often those errors >> slip through. >> > > >> > >> > Furthermore, since I (as a committer) cannot guarantee >> that I reviewed every change to every file between release a >> and release b I cannot, as a PMC member, be certain that the >> necessary files are present and correct. If I were to vote >> +1 without having reviewed the release then my vote would be >> worthless when it comes to demonstrating that our policy has >> been followed for that release. >> > > >> > > Ross >> > > >> > > >> > > >> > > >> > > >> > > >> > > On 27 May >> 2014 10:25, Brian LeRoux wrote: >> > > From my perspective this is a daily >> requirement of a responsible committer. That final check >> isn't hurting anything but it is not even remotely >> acceptable for a committer to not be constantly vigilant >> when landing commits to our source. >> > >> > >> > > >> > > On >> Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen >> wrote: >> > > Ross Gardler wrote: >> > > >> > > > In my >> mind (and I am not a lawyer so that means almost nothing in >> these situations) the requirement to have 3 PMC members >> indicate that, to the best of their knowledge, the release >> is compliant with the policy is sufficient. >> > > >> > > >> > > >> > > Leaving my >> lawyer hat off for a bit, it seems so to me too. I'm not >> worried. I wasn't even worried about that when I served >> on the board. /Larry >> > > >> > > >> > > >> > > From: Ross Gardler [mailto:rgardler@opendirective.com] >> > > Sent: Saturday, May 24, 2014 8:08 >> PM >> > > To: legal-discuss@apache.org; >> Larry Rosen >> > > Subject: Re: >> Clarification about D&O insurance and bad acts >> > > >> > > >> >> > > >> > >> > >> > > >> > > >> > > >> > > >> > >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org >> > For additional commands, e-mail: legal-discuss-help@apache.org >> > >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org >> For additional commands, e-mail: legal-discuss-help@apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org >> For additional commands, e-mail: legal-discuss-help@apache.org >> >> > --f46d043be038da1ee104fa8b1e49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 9 May 2014 15:54, Stephen Connolly <stephen.alan.connolly@gm= ail.com> wrote:
Actually I like the QA= analogy ;-)

And a QA department is not going to check = every toy in every batch of toys.... instead they will do a random check...= either checking one toy at random in each batch (or a fraction of batches)= , or checking all toys in a small fraction of batches.

Oh! and if they find a failure then they w= ill obviously call halt and start checking more... and only reduce the leve= l of checks once things return to normal.
=C2=A0

So following the QA analogy, if each PMC member does some ra= ndom spot-checks as a QA assurance that the required buts are present... wo= uld that be OK?=C2=A0


On 29 May 2014 13:14, Mark Struberg <struberg@yahoo.de> wrot= e:
+1

Think about it like a QA department of a production line in a company build= ing children toys.

Of course all employees take care to not introduce a failure which might ha= rm children. But even then it _might_ happen.

Now what would happen if such a failure really appears? They would sue the = hell out of this company...

By having a QA department which does an independent check if all is fine ov= er and over again this risk might get reduced. And even if a failure still = slips through it will help the company to not get hit too hard at least.
LieGrue,
strub

--------------------------------------------
On Thu, 29/5/14, Jim Jagielski <jim@jaguNET.com> wrote:

=C2=A0Subject: Re: Clarification about D&O insurance and bad acts
=C2=A0To: legal-discuss@apache.org
=C2=A0Date: Thursday, 29 May, 2014, 13:49

=C2=A0Not sure what you mean by
=C2=A0that... One of the aspects
=C2=A0of verifying a
=C2=A0release is checking that the bits going out
=C2=A0are, in fact, the expected and correct bits...
=C2=A0which sounds
=C2=A0like src verification to me.
=C2=A0And is, obviously, appropriate
=C2=A0and
=C2=A0necessary.

=C2=A0On May 28, 2014,
=C2=A0at 2:47 PM, Brian LeRoux <b@brian.io> wrote:

=C2=A0> Agreed! That said, src
=C2=A0verification for releases is not always appropriate or
=C2=A0necessary. (Depending on the project, the people and their
=C2=A0unique attributes.)
=C2=A0>
=C2=A0> On May 28, 2014 1:01 PM, "Jim
=C2=A0Jagielski" <jim@jagunet.com>
=C2=A0wrote:
=C2=A0> That is true. But doing normal
=C2=A0work-in-progress, and the
=C2=A0> oversight
=C2=A0thereof, is a different thing than doing a
=C2=A0> release.
=C2=A0>
=C2=A0> One does not negate the other, nor does it
=C2=A0remove the
=C2=A0> need for the other. Saying
=C2=A0"we do X oversight for our day
=C2=A0> to
=C2=A0day development" does not mean that no oversight is
=C2=A0> needed for a release, simply because
=C2=A0it's a different
=C2=A0> kind of oversight
=C2=A0for a different kind of activity.
=C2=A0>
=C2=A0> On May 27, 2014, at 5:22 PM, Brian LeRoux
=C2=A0<b@brian.io>= ; wrote:
=C2=A0>
=C2=A0> > We could both
=C2=A0wax hypothetical about the merit of humans and error
=C2=A0proneness. My point is whatever is work-in-progress is a
=C2=A0daily responsibility and not something to be left for the
=C2=A0last minute check by others. Ever.
=C2=A0>
=C2=A0>
=C2=A0> >
=C2=A0> > On
=C2=A0Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rgardler@opendirective.com>= ;
=C2=A0wrote:
=C2=A0> > Brian, you are absolutely
=C2=A0correct. However, SVN is not the release and so having
=C2=A0reviewed commits is not the same as having reviewed the
=C2=A0release. In a well run project where people are reviewing
=C2=A0code commits there should be no problem. But people make
=C2=A0errors and you would be surprised how often those errors
=C2=A0slip through.
=C2=A0> >
=C2=A0>
=C2=A0> Furthermore, since I (as a committer) cannot guarantee
=C2=A0that I reviewed every change to every file between release a
=C2=A0and release b I cannot, as a PMC member, be certain that the
=C2=A0necessary files are present and correct. If I were to vote
=C2=A0+1 without having reviewed the release then my vote would be
=C2=A0worthless when it comes to demonstrating that our policy has
=C2=A0been followed for that release.
=C2=A0> >
=C2=A0> > Ross
=C2=A0> >
=C2=A0> >
=C2=A0> >
=C2=A0> >
=C2=A0> >
=C2=A0> >
=C2=A0> > On 27 May
=C2=A02014 10:25, Brian LeRoux <b@brian.io> wrote:
=C2=A0> > From my perspective this is a daily
=C2=A0requirement of a responsible committer. That final check
=C2=A0isn't hurting anything but it is not even remotely
=C2=A0acceptable for a committer to not be constantly vigilant
=C2=A0when landing commits to our source.
=C2=A0>
=C2=A0>
=C2=A0> >
=C2=A0> > On
=C2=A0Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lrosen@rosenlaw.com>
=C2=A0wrote:
=C2=A0> > Ross Gardler wrote:
=C2=A0> >
=C2=A0> > > In my
=C2=A0mind (and I am not a lawyer so that means almost nothing in
=C2=A0these situations) the requirement to have 3 PMC members
=C2=A0indicate that, to the best of their knowledge, the release
=C2=A0is compliant with the policy is sufficient.
=C2=A0> >
=C2=A0> >
=C2=A0> >
=C2=A0> > Leaving my
=C2=A0lawyer hat off for a bit, it seems so to me too. I'm not
=C2=A0worried. I wasn't even worried about that when I served
=C2=A0on the board. /Larry
=C2=A0> >
=C2=A0> >
=C2=A0> >
=C2=A0> > From: Ross Gardler [mailto:rgardler@opendirective.com]
=C2=A0> > Sent: Saturday, May 24, 2014 8:08
=C2=A0PM
=C2=A0> > To: legal-discuss@apache.org;
=C2=A0Larry Rosen
=C2=A0> > Subject: Re:
=C2=A0Clarification about D&O insurance and bad acts
=C2=A0> >
=C2=A0> >
=C2=A0<snip>
=C2=A0> >
=C2=A0>
=C2=A0>
=C2=A0> >
=C2=A0> >
=C2=A0> >
=C2=A0> >
=C2=A0>
=C2=A0>
=C2=A0>
=C2=A0---------------------------------------------------------------------=
=C2=A0> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<= br> =C2=A0> For additional commands, e-mail: legal-discuss-help@apache.org
=C2=A0>



=C2=A0---------------------------------------------------------------------=
=C2=A0To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
=C2=A0For additional commands, e-mail: legal-discuss-help@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org



--f46d043be038da1ee104fa8b1e49--