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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
