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 22:22:55 GMT
robert burrell donkin wrote:
> please reread carefully the actual comment

Gotcha - more of what I agreed with deeper into your post.

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

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

It already IS.  What you are proposing is today's policy.  Today's policy
permits one individual 'manage' all the submissions from their 'primary'
project or company.  This is the badness that my proposal seeks to end
by forcing that code out into the open by the submittor prior to commit.

Today - your companies' work on project Foo is covered by a CCLA, so there
is no obstacle to your committing the work of all the other employees with
no peep from them on the dev lists.  While I don't argue it's necessary
to deal with the initial 'code import' that way, some projects feel that
they can continue to operate that way.  I wish to end this.

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

>> There's no difference, both are bad situations - the rational is the
>> only distinction
> there are major differences from the legal perspective

Yet another distinction without a difference.

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

I agree.

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

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

View raw message