robert burrell donkin wrote: > On 2/3/07, Ted Husted <[EMAIL PROTECTED]> wrote: >> On 2/2/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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. Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
