incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <>
Subject Re: [Vote] Incubating Project Policy
Date Sun, 04 Feb 2007 22:42:35 GMT
On 2/4/07, William A. Rowe, Jr. <> wrote:
> robert burrell donkin wrote:


> >> 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
> Howso?  You 'directly' commit your own stuff or you commit stuff first
> proposed on the 'list' (dev@, bugzilla, jira).
> 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

correct attribution is therefore vital: i need to say "feature X is
total fantastic and here some code i found on web/a friend
wrote/whatever that nearly implements it". i agree that from a
community perspective, this should be tacked on list rather than CTR
but the attribution is vital from a legal perspective.


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


> > 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.
> Yes - the thread's grown too long - it needs summarization.  Early in the
> week I'll start a wiki page to begin the clarifications (whys) and let
> folks add-on other examples (which are scattered right now throughout
> this thread.)


- robert

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

View raw message