Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Subject: Re: Continuous release review
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: <5388750D.90808@gmail.com>
Date: Fri, 30 May 2014 08:22:57 -0400
Cc: Apache Board <board@apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <759D11D5-CC69-4499-9826-60F807492DF1@jaguNET.com>
References: 
 <CAOFYJNaqACY-JXUesx-V0PnsiCCkfVo_xKdEMO-N5Nt7Y_JTFQ@mail.gmail.com>
 <6F8EDB3F-12C5-4D0C-A379-E9AB4F99F391@jaguNET.com>
 <B97B3DBD-2937-4BE0-A127-92ED5B27ED84@jaguNET.com>
 <CFAB643C.22DBD%aharui@adobe.com>
 <C174F6FF-BC2C-43F0-8191-CDA3D25D4E61@jaguNET.com>
 <CAOFYJNbZRwxQMtja2NDLCR=L7FKscRjwG2r-iBHRK0+_KUJP9A@mail.gmail.com>
 <8EADF702-6B7B-4B26-A867-61EC3C6FCFB8@jaguNET.com>
 <53873990.5060601@gmail.com>
 <47681A1F-924F-496F-8209-46EF3EDB7F02@jaguNET.com> <53875212.20308@gmail.com>
 <80083BE7-9F6C-43DC-A97F-9AED674C9B98@jaguNET.com> <5388750D.90808@gmail.com>
To: legal-discuss@apache.org

The Board expects the PMC to do its job, and the
Board expects the PMC Chair to do his/her job.

If they don't, the board acts; and, as has been said
many times, the board is not a surgical scalpel; it
is a hammer.

On May 30, 2014, at 8:09 AM, Emmanuel L=E9charny <elecharny@gmail.com> =
wrote:

> Le 29/05/2014 17:47, Jim Jagielski a =E9crit :
>> On May 29, 2014, at 11:28 AM, Emmanuel L=E9charny =
<elecharny@gmail.com> wrote:
>>=20
>>> Le 29/05/2014 15:56, Jim Jagielski a =E9crit :
>>>> I disagree. And until the policy is changed, PMCs and
>>>> RMs are expected and *required* to comply.
>>> Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
>>>=20
>>> ...
>>> And, yes, it's probably a good idea to fix the policy if it can't be
>>> enforced.
>>>=20
>> To be clear: If it is found out that there are "releases" out
>> there that really aren't releases, the board will tell the
>> PMC to:
>>=20
>>  1: Remove those releases immediately.
>>  2: Re-release those "releases" as real releases
>>     by complying w/ the release policy (basically,
>>     taking those "releases" and doing the required
>>     vetting and voting).
>>=20
>> The board can, and will, also remove a PMCs ability
>> to "release" stuff if it refuses to comply with the
>> release policy. So it can be enforced. It is being
>> enforced. It will be enforced.
>=20
> This is not an enforcement. This is a punishment. And it's totally =
vain.
>=20
> Unless the board is ready to check all the releases for all the 151
> projects, and verify that *every* PMC member is eventually going =
through
> the whole process, this is just a void statement.
>=20
> Btw, just tell me how you are going to control that ? I'm curious...
> OTOH, we van make it easier for the PMC members to cast a vote, by
> verifying the output of a documented/replayable process, which will =
take
> a few minutes instead of hours in some cases. How possibly can someone
> object that it would be a progress ?
>=20
>=20
>=20
> ---------------------------------------------------------------------
> 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