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 should. More eyes are better, that's why I proposed the policy. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
