Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of robertburrelldonkin@gmail.com
 designates 64.233.184.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=H4+uQ6Nbgf6W+/j4SfKdxkWmcCb02SVjgxaYcYFwDXl+ZDtnDPIzMHsk5j58bpkFZw2H4bMRc2mMbFNu0D2KFVnOVwD1Wz7sxpM8ltvJhaBIXm/YSOgIuwMsvesrPCTAYoAXbdnMPP+O5i+/gGBBOt5F5pvn139pGe+8W7802/0=
Message-ID: <f470f68e0702050519o7b2f79d0g991de885db244577@mail.gmail.com>
Date: Mon, 5 Feb 2007 13:19:39 +0000
From: "robert burrell donkin" <robertburrelldonkin@gmail.com>
To: general@incubator.apache.org
Subject: Re: [Vote] Incubating Project Policy
In-Reply-To: <45C66746.80505@rowe-clan.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <NBBBJGEAGJAKLIDBKJOPAELMMMAC.noel@devtech.com>
	 <8b3ce3790702021333w70bb876asecd07f2f37963702@mail.gmail.com>
	 <45C3B476.6070008@rowe-clan.net>
	 <8b3ce3790702030656l4a0c035do9b189d71f5c8bc97@mail.gmail.com>
	 <f470f68e0702040642w42f86991t5e46c53fbd03b6b5@mail.gmail.com>
	 <45C6452E.2050201@rowe-clan.net>
	 <f470f68e0702041326h52824e3ct6db171f1bc3365a0@mail.gmail.com>
	 <45C65CBF.9090505@rowe-clan.net>
	 <f470f68e0702041442yb418731w2752ab4beadbd8cf@mail.gmail.com>
	 <45C66746.80505@rowe-clan.net>

On 2/4/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> robert burrell donkin wrote:
> >>
> >> Please give me a case where back channel commits are permitted under
> >> the proposed commit policy?
> >
> > the wording does not make clear the intention of the rule
> >
> > for example, i post: "feature X is totally fantastic and i've attached
> > some code that nearly implements it"  the consensus is: "that's
> > totally cool: commit it right away". so i do.
> >
> > but the community never knew that the code wasn't mine to commit
>
> You committed fraud.  I propose (in the private@ pmc list) to turn off
> your commit access if/when this is discovered.

it isn't fraud unless i misrepresent the attribution

in above example, i simply neglected to mention the origin of the
code. maybe i made an honest mistake: unless it's made clear that
every contribution which is not an original contribution by the
contributor requires attribution then these will happen.

> This policy isn't ment to cover every base; no policy should.  Sure we
> can add a section on fraud/ethics, but that's a different matter.

the new policy addresses the concern neither directly or effectively

without insisting on attribution, it's a waste of time

<snip>

> >> No need in some cases.  At httpd and apr, for example, they bundle the
> >> pcre, expat etc.  It was handled correctly, licenses were checked.  But
> >> the choice to bump expat to 1.95.8 or 2.0.0 is a community decision.
> >
> > need to check the wording of the board resolution: it's possible that
> > this should have been a community decision but cleared through the
> > incubator
>
> Those predate the incubator.  Call it grandfathered.  They didn't become
> ASF projects, either - they are external bundled dependencies.
>
> In the future you would be correct.  Pre-announcing the desire to pull in,
> say, libxslt would trigger someone on the list to say 'slow down, we need
> to run that through Incubator for IP clearance' if things work as they
> should.

community approval of an external dependency is different from legal
clearance for a particular artifact. whenever the artifact is updated,
it probably needs to be cleared for IP.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org