www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Clarification about D&O insurance and bad acts
Date Thu, 29 May 2014 16:00:13 GMT
On 29 May 2014 16:55, Jim Jagielski <jim@jagunet.com> wrote:

>
> On May 29, 2014, at 11:50 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On 29 May 2014 16:07, Jim Jagielski <jim@jagunet.com> wrote:
> > Except we don't make a "batch" of toys... Just one.
> >
> > I think you are counting wrong!
> >
> > The release.src.tar.gz is the batch...
> >
> > Depending on how you look at it, it is either a batch of files or a
> batch of commits.
>
> That's like looking at "a toy" and saying it's a batch of parts... :)
>

Well a file is a batch of bytes... you put the bytes together to make the
file... Oh and you can play with a file and break it into its constituent
parts... and if you break it into all its parts and jumble them up again it
can be very hard to put the file back together the way it was before you
broke it apart (you should see my son play with Lego)

I think the "release == batch" analogy still holds ;-)


>
> >
> > So the QA analogy is that you inspect some (or none... it's a random
> thing ;-) ) of the files to ensure that they have the license details and
> that the commit history of the file is good and ... etc
> >
> > Or if you want to view as a batch of commits, you pick some/none (random
> sampling again) of the commits that is new to the release and trace them.
> >
> > Our releases are not toys ;-)
> >
> >
> > Which makes the QA job easier... right? The reason they don't
> > QA all is because they don't have the time and resources.
> >
> > And we don't have the time and resources to do the full set of checks
> that we need to do... heck I'm not even 100% certain of the full set of
> checks... mostly I just:
> >
> > * checks the commits since the last release to see if there is anything
> strange or an atypical committer
> > * check the RAT report
> > * check that it matches source control + the files generated via
> consistent repeatable processes
> > * check that it builds and (where present) tests pass
> > * maybe give it a sanity test
> > * cross my fingers and hope I have remembered everything that I am
> supposed to do.
> >
> > Worse still, I'm the PMC chair and I remember reading that the PMC chair
> role has added responsibilities from a legal perspective (I am sure these
> are covered by the insurance... but it's a worry)
> >
> > And some places *do* QA each and every thing that
> > goes out, and take great pride in doing so.
> >
> > On May 29, 2014, at 10:54 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.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.
> > >
> > > 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 <struberg@yahoo.de> 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 <jim@jaguNET.com> 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 <b@brian.io> 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" <jim@jagunet.com>
> > >  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
> > >  <b@brian.io> 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 <
> rgardler@opendirective.com>
> > >  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 <b@brian.io> 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 <lrosen@rosenlaw.com>
> > >  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
> > >  > >
> > >  > >
> > >  <snip>
> > >  > >
> > >  >
> > >  >
> > >  > >
> > >  > >
> > >  > >
> > >  > >
> > >  >
> > >  >
> > >  >
> > >  ---------------------------------------------------------------------
> > >  > 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
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

Mime
View raw message