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 66.249.92.174 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=R4TcpCOhRFWliS1jch2B1O5j69U27PbddoeedWaDJPee6IWLPqAscSpgx2jTxPgCAWADHaX4X4vVxSTKRVx9teUqz16IlznUeU6rbjAkYvja4uPDHuKqfqtIhaHZskXDW3DWnhrRcVaJJvxNMf0hnNuQbI+1TMNsMd1c0yxY/Mc=
Message-ID: <f470f68e0702041326h52824e3ct6db171f1bc3365a0@mail.gmail.com>
Date: Sun, 4 Feb 2007 21:26:35 +0000
From: "robert burrell donkin" <robertburrelldonkin@gmail.com>
To: general@incubator.apache.org
Subject: Re: [Vote] Incubating Project Policy
In-Reply-To: <45C6452E.2050201@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>
	 <45C27EF2.1050003@rowe-clan.net> <45C28774.2050109@rowe-clan.net>
	 <8b3ce3790702021333w70bb876asecd07f2f37963702@mail.gmail.com>
	 <45C3B476.6070008@rowe-clan.net>
	 <8b3ce3790702030656l4a0c035do9b189d71f5c8bc97@mail.gmail.com>
	 <f470f68e0702040642w42f86991t5e46c53fbd03b6b5@mail.gmail.com>
	 <45C6452E.2050201@rowe-clan.net>

On 2/4/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> robert burrell donkin wrote:
> > On 2/3/07, Ted Husted <husted@apache.org> wrote:
> >> On 2/2/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> >>> If they aren't a committer yet, they post a patch (jira or list) just like
> >>> every other wannabe future committer.  When the volume and quality are
> >>> reasonable, they are offered commit access.  But the suggested policy is to
> >>> state "no backchannel dealings with codesubmissions.  bring it to the list."
> >>
> >> Agreed, but a detailed Subversion log is also part of the list. If the
> >> Subversion entry details the source of the commit, cites a CLA, and
> >> includes the design justification, then that's no different than
> >> bringing it up on the list as a matter of lazy consensus. Over the
> >> long term, it may be even better, since the information is attached to
> >> the commit, and not just floating around on the dev list.
> >
> > +1
>
> -1 - actually we poison svn history, and create larger issues for our svn
> admins when someone does polute a project with IP infringing commits.  The
> svn history remains forever unless someone goes in and munges the records
> and that's a PITA.  Since in limited cases we actually undo the original
> commit, wasting much of admin time.

please reread carefully the actual comment

> I don't agree with this answer.  How did you put your hands on the proposed
> code?  Either it was back channeled to you (bad) or you unilaterally decided
> to include 3rd party code (bad).

in ted's example, the committer would need to actively and
intentionally lie in the commit message before bad IP was committed.
we can do very little about this.

> > there are two different standards which need to be applied to two
> > difference classes of document:
> >
> > * donations (whether covered by a CLA, JIRA opt in or a software grant)
> > * others (should be covered by compatible licenses)
> >
> > i'm not sure that the proposed policy correctly capture this difference
>
> It deliberate doesn't distinguish (echo; think I said this already).

i'm not sure that incubator policy should intentionally set out to
obfuscate and confuse :-/

> In
> the first case, the reason is that patches should be publicly offered and
> not privately back-channeled, iCLA or no.  We don't have svnmongers here.
> "Future" committers should participate publicly.  Current committers should
> be committing their own code (making and correcting their own snafus.)
> You learn nothing as a committer having someone else do your commits for
> you, you learn nothing of the community process as a future committer when
> you back channel all your ideas to a specific individual/coworker/whatever.

the problem with your wording is that it does not address
backchanneling but does introduce a new and somewhat irrational and
inexplicable rule

what matters is the origin of the code not whether it's posted to the
list or not. if this is a significant issue then the right way to
address this issue would be to insist that all code not covered by a
software grant, a CLA or JIRA be subject to the usual IP clearance
process.

> The second case, the reason is that bringing in compatible code that you
> did not write should not be your unilateral action, it should be the
> consensus of the project.

then all projects (not just podling) should submit new third party
code for IP clearance here

> There's no difference, both are bad situations - the rational is the
> only distinction

there are major differences from the legal perspective

<snip>

> >> To me, this sounds like an issue with the Subversion log entries.
> >
> > +1
>
> -1 - attribution actually was -not- one of the issues that prompted this
> proposal.  I agree with you it's important, and should be explicitly
> spelled out.  But I personally wouldn't want to comingle - the proposal
> was about fostering community, self-sufficient committers and open dialog
> about the code base.

if the proposal is about those qualities then i strongly suggest that
you clarify the wording

what would probably more effective in the long run that arguing about
the rule would be if you could find time to write up some material on
community building and the importance of bringing code to the list to
help explain the meaning of the rule.

- robert

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