incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: [Vote] Incubating Project Policy
Date Sun, 04 Feb 2007 20:42:22 GMT
robert burrell donkin wrote:
> On 2/3/07, Ted Husted <> wrote:
>> On 2/2/07, William A. Rowe, Jr. <> 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.

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).

> 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).  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 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.

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

> it is important that committers understand that they need to be
> certain that if the code is not an original work covered by a CLA they
> need to note that in the commit record

That too, of course.  I don't disagree here.

> the origin of the code matters and needs to be recorded in the commit
> message. conventionally, it is expected that any code that is not
> originally created for apache by the contributor has appropriate
> attribution in the commit notice

plus NOTICE where the license requires advertisement.  Of course.

> this seems important and needs to be documented somewhere, i think

I concur.

>> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message