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 23:07:50 GMT
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.

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.

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

We don't disagree 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
> 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

More eyes are better, that's why I proposed the policy.

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

View raw message