Re: [Vote] Incubating Project Policy
On Sunday 04 February 2007 22:42, robert burrell donkin wrote: * donations (whether covered by a CLA, JIRA opt in or a software grant) Shouldn't we avoid the word donation?? Code is not donated to ASF, it is licensed. Time is perhaps donated to ASF, but not IP... Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
On 2/5/07, Niclas Hedhman [EMAIL PROTECTED] wrote: On Sunday 04 February 2007 22:42, robert burrell donkin wrote: * donations (whether covered by a CLA, JIRA opt in or a software grant) Shouldn't we avoid the word donation?? Code is not donated to ASF, it is licensed. Time is perhaps donated to ASF, but not IP... i tried to think of a better word :-/ anyone think of a better short term for 'covered by CLA, software grant or AL2.0#5'...? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
On 2/4/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: 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. it isn't fraud unless i misrepresent the attribution in above example, i simply neglected to mention the origin of the code. maybe i made an honest mistake: unless it's made clear that every contribution which is not an original contribution by the contributor requires attribution then these will happen. 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. the new policy addresses the concern neither directly or effectively without insisting on attribution, it's a waste of time snip 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. community approval of an external dependency is different from legal clearance for a particular artifact. whenever the artifact is updated, it probably needs to be cleared for IP. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
robert burrell donkin wrote: On 2/5/07, Niclas Hedhman [EMAIL PROTECTED] wrote: On Sunday 04 February 2007 22:42, robert burrell donkin wrote: * donations (whether covered by a CLA, JIRA opt in or a software grant) Shouldn't we avoid the word donation?? Code is not donated to ASF, it is licensed. Time is perhaps donated to ASF, but not IP... i tried to think of a better word :-/ contributions? -jean anyone think of a better short term for 'covered by CLA, software grant or AL2.0#5'...? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
--- Ted Husted [EMAIL PROTECTED] wrote: On 2/5/07, Niclas Hedhman [EMAIL PROTECTED] wrote: On Sunday 04 February 2007 22:42, robert burrell donkin wrote: * donations (whether covered by a CLA, JIRA opt in or a software grant) Shouldn't we avoid the word donation?? Code is not donated to ASF, it is licensed. Time is perhaps donated to ASF, but not IP... I believe people are donating a copyright to the code. A license doesn't transfer copyright or make another party the copyright holder. In the case of these commits, the ASF is becoming a joint copyright holder to the work. Since we are a non-profit organization that solicits monetary donations, I don't see why we would shy away from the word donate when we are talking about IP. In the case of our own commits, as copyright holders, we are donating (or contributing) to the ASF a non-exclusive copyright, and then we are committing the donation/contribution as an authorized representative of the ASF. It's a two hat process :) -Ted. First off let me say, I'm greatly enjoying this discussion. My understanding is the piece of work that is being discussed is the patch/diff/zip/tar file that is being distributed to the ASF through CLA, JIRA, Bugzilla and software grant contributions. Generally, no one is assigning their copyright of the patch/diff/zip/tar file to the ASF, they are only granting them license to modify it and include it in a larger work (amongst other things). The ASF owns the copyright of the larger work. -Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
On 2/5/07, Niclas Hedhman [EMAIL PROTECTED] wrote: On Sunday 04 February 2007 22:42, robert burrell donkin wrote: * donations (whether covered by a CLA, JIRA opt in or a software grant) Shouldn't we avoid the word donation?? Code is not donated to ASF, it is licensed. Time is perhaps donated to ASF, but not IP... I believe people are donating a copyright to the code. A license doesn't transfer copyright or make another party the copyright holder. In the case of these commits, the ASF is becoming a joint copyright holder to the work. Since we are a non-profit organization that solicits monetary donations, I don't see why we would shy away from the word donate when we are talking about IP. In the case of our own commits, as copyright holders, we are donating (or contributing) to the ASF a non-exclusive copyright, and then we are committing the donation/contribution as an authorized representative of the ASF. It's a two hat process :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
On 2/5/07, Ted Husted [EMAIL PROTECTED] wrote: I believe people are donating a copyright to the code. A license Well, the problem with that phrasing is that most people would wrongly assume 'donating a copyright' means 'donating the copyright ownership' - it's way too subtle. We all know that they are *not* transferring the copyright ownership - they are simply sharing it with us under a license. (This is the true Jeffersonian ideal.) Hence, find another word for 'copyright' (they are also granting patent rights too) to remove the ambiguity. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
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]
Re: [Vote] Incubating Project Policy
On 2/4/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: 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. please reread carefully the actual comment 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). in ted's example, the committer would need to actively and intentionally lie in the commit message before bad IP was committed. we can do very little about this. 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). i'm not sure that incubator policy should intentionally set out to obfuscate and confuse :-/ 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 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. 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 There's no difference, both are bad situations - the rational is the only distinction there are major differences from the legal perspective snip 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 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. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
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]
Re: [Vote] Incubating Project Policy
On 2/4/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: robert burrell donkin wrote: snip 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? 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 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. snip 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. 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 snip 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.) +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
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]
Re: [Vote] Incubating Project Policy
On 2/2/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: James Margaris wrote: -1 from me. (If I even have a vote...) Although only ASF members/Incubator PMC votes are 'counted', yes everyone here has a voice - we do appreciate everyone's input. So should every podling. +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
+1 to Bill's suggestion of having an ASF Commit Policy - but there are many points in this thread that would be good to be incorporated in his original suggestion. Niall 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. Any controversial commit should be discussed first, regardless of its source. Committers need to apply the same good judgment and discretion to our own donations as we do to the donations of others. I think a key problem with this policy is that it implies we can apply a different standard to our own donations. A key idea is that the PMC is accepting donations on behalf of the foundation. Whether the donation is code we happen to write, or someone else has donated, isn't important. When I commit code I wrote, I may be sheparding my own donation, but, I'm still not committing as the author, but as a PMC member authorized to accept donations on behalf of the foundation, including those I happened to write myself. Otherwise we'll fail to recognize the merits of *individual's* contributions and therefore won't offer commit access when it's warrented. And *that* is the third part of the issue. To me, this sounds like an issue with the Subversion log entries. The source of all donations must be cited so that there is a clear providence for the work. If we don't cite a source, then the assumption is that the committer is also the donor. Every commit is a donation, and every commit has an explicit or implied donor. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
On 2/2/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: ...I'm proposing the following policy become explicit across the incubator;.. I'm +1 on the idea, with a suggestion below. ...committers may commit code they personally authored, or with proper attribution, commit patches posted .. I'd add by their original authors or license holders here to make it clear that posting to Jira by proxy is not allowed either. ...on the project's mailing list or posted to the project's bug tracking system (Jira/Bugzilla)... ... directly committed without first posing the submission ... typo here, T missing in posting. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
I am +1 on this and the main reason for this is that people that become committers through the incubator don't necessarily have any experience with apache projects and how issues like this are normally handled. As a side effect it gives us the option to link to this policy in case something like this would happen in non incubating projects. The only thing that would be nice to add to the policy is a more clear description of why this policy is there. It's often better to say why things are in place, people can also apply this knowledge to other scenario's that they might encounter. Mvgr, Martin William A. Rowe, Jr. wrote: I believe many projects practice this policy, although it's unwritten, and perhaps there are others who don't (and probably deserve some scrutiny to determine if it's helpful or harmful). I'm proposing the following policy become explicit across the incubator; Where the project policy permits commit-then-review contributions to its Subversion repository, committers may commit code they personally authored, or with proper attribution, commit patches posted on the project's mailing list or posted to the project's bug tracking system (Jira/Bugzilla). No third-party code (beyond bugzilla and mailing list submissions) may be directly committed without first posing the submission to the mailing list. This goes for submissions by associates who are unaffiliated with the project, private correspondence to a committer, and third party open source code which is otherwise compatible with the Apache Software License. Where the project's policy is review-then-commit, there truly is no change to their current practice. All of the above cases are subject to review first on the mailing list. I believe the policy would directly address not only concerns w.r.t. the Heraldry project, but several prior issues and those that will still pop up over the horizon. Votes? +1 here. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
Bertrand Delacretaz wrote: On 2/2/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: ...I'm proposing the following policy become explicit across the incubator;.. I'm +1 on the idea, with a suggestion below. ...committers may commit code they personally authored, or with proper attribution, commit patches posted .. I'd add by their original authors or license holders here to make it clear that posting to Jira by proxy is not allowed either. +1, with Bertrand's addition. The UIMA podling follows this policy, not because we have issues with third-party contributions but to keep our IP squeaky clean. [We have the additional constraint that we don't commit anything (other than trivial changes) by people who do not have an ICLA on file. It has been suggested that this sets the bar very high for potential contributors, but from our (limited) experience so far, this does not seem to be the case.] --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
Bertrand Delacretaz wrote: On 2/2/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: ...I'm proposing the following policy become explicit across the incubator;.. I'm +1 on the idea, with a suggestion below. ...committers may commit code they personally authored, or with proper attribution, commit patches posted .. I'd add by their original authors or license holders here to make it clear that posting to Jira by proxy is not allowed either. ...on the project's mailing list or posted to the project's bug tracking system (Jira/Bugzilla)... ... directly committed without first posing the submission ... typo here, T missing in posting. I'd add clarification about 'committing third party code' with reference to libraries. I should be able to commit the latest log4j jar without having to do any jira nuisance. This is about committing the code itself as a contribution, not as a dependency. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
William A. Rowe, Jr. wrote: Upayavira wrote: I'd add clarification about 'committing third party code' with reference to libraries. I should be able to commit the latest log4j jar without having to do any jira nuisance. This is about committing the code itself as a contribution, not as a dependency. I deliberately included libraries as third party code. Including (for example) log4j in your project, and deciding how 'fresh' (bleeding edge? advertised stable? last known stable?) of a version the project should bump it to. You might even discover that there is an issue with the version you want to adopt that's known to another project contributor. There's nothing unreasonable about posting I'm bumping our log4j to trunk to resolve our interop bugs with ... before you do so, right? Yep, true enough. Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Vote] Incubating Project Policy
Doesn't this fall under the general develop on the list practice? I would assume that developing on the list includes mentioning when you are going to do something like swap out a library for a newer version. Can someone articulate what problem this new policy proposal is addressing and how it addesses it? It is very difficult for me to see what the goal here is and if that goal is being achieved. James Margaris -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Friday, February 02, 2007 2:35 PM To: general@incubator.apache.org Subject: Re: [Vote] Incubating Project Policy William A. Rowe, Jr. wrote: Upayavira wrote: I'd add clarification about 'committing third party code' with reference to libraries. I should be able to commit the latest log4j jar without having to do any jira nuisance. This is about committing the code itself as a contribution, not as a dependency. I deliberately included libraries as third party code. Including (for example) log4j in your project, and deciding how 'fresh' (bleeding edge? advertised stable? last known stable?) of a version the project should bump it to. You might even discover that there is an issue with the version you want to adopt that's known to another project contributor. There's nothing unreasonable about posting I'm bumping our log4j to trunk to resolve our interop bugs with ... before you do so, right? Yep, true enough. Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
Ted Husted wrote: I think the real issue here is off-list discussions. Third is, yes. The other two thirds... So long as the commit is above-board, properly documentation in the Subversion log, and backed by a ICLA when applicable, I don't see what difference posting it to JIRA first makes. We are talking about someone committing on behalf of another person. So... how do we make educated committers if we don't let them commit their own code, and avoid roles like 'code managers' to supervise others commits? Once you are trusted to commit your code yourself, please do. The Jira/Bugzilla/dev list point is to say HEY - you want to offer us code, then offer it! No backchannels. That's the third third. 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. Otherwise we'll fail to recognize the merits of *individual's* contributions and therefore won't offer commit access when it's warrented. And *that* is the third part of the issue. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Vote] Incubating Project Policy
I believe many projects practice this policy, although it's unwritten, and perhaps there are others who don't (and probably deserve some scrutiny to determine if it's helpful or harmful). I'm proposing the following policy become explicit across the incubator; Where the project policy permits commit-then-review contributions to its Subversion repository, committers may commit code they personally authored, or with proper attribution, commit patches posted on the project's mailing list or posted to the project's bug tracking system (Jira/Bugzilla). No third-party code (beyond bugzilla and mailing list submissions) may be directly committed without first posing the submission to the mailing list. This goes for submissions by associates who are unaffiliated with the project, private correspondence to a committer, and third party open source code which is otherwise compatible with the Apache Software License. Where the project's policy is review-then-commit, there truly is no change to their current practice. All of the above cases are subject to review first on the mailing list. I believe the policy would directly address not only concerns w.r.t. the Heraldry project, but several prior issues and those that will still pop up over the horizon. Votes? +1 here. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Vote] Incubating Project Policy
-1 from me. (If I even have a vote...) If I want to check in some third party code with a proper license, I don't really see the difference between checking it in directly vs. posting it to Jira and then checking it in. Is there some sort of implied waiting period during which people review the Jira patches? I also don't see why this is a case to protect against. If the policy of the project is to allow third party open source code with a compatible license and the policy is also commit-then-review, what is the issue? It seems this erases the distinction between commit-then-review and review-then-commit. It appears to me that the system is basically working. The Heraldry project has some issues, people spotted them, now appropriate action is being taken. According to the documentation mentors are supposed to keep their eyes open for these sorts of problems. I don't see how this addresses the Heraldry problems. If they want to do a massive commit of externally developed changes they would now post them as a patch first (or mailing list message) and then commit them instead of just committing them - the end result is the same no? To me that is just transferring the problem, now instead of a massive commit of external stuff you get a massive email message with that same externally developed stuff in it. The problem is that a bunch of external development is going on while the mailing list is silent, and this doesn't address that. I don't think there is any great way to prevent this sort of thing other than make it clear that it won't be tolerated and encouraging vigilance from the project mentors. What I find a bit disturbing about this Heraldry business and the Kabuki fiasco before it is the lack of any communication out of the project. I would expect explanations from multiple committers, promises to do better, pleas for clarification or something of the sort. Maybe I've missed it but the Heraldry community seems pretty silent. James Margaris From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Thu 2/1/2007 4:36 PM To: general@incubator.apache.org Subject: [Vote] Incubating Project Policy I believe many projects practice this policy, although it's unwritten, and perhaps there are others who don't (and probably deserve some scrutiny to determine if it's helpful or harmful). I'm proposing the following policy become explicit across the incubator; Where the project policy permits commit-then-review contributions to its Subversion repository, committers may commit code they personally authored, or with proper attribution, commit patches posted on the project's mailing list or posted to the project's bug tracking system (Jira/Bugzilla). No third-party code (beyond bugzilla and mailing list submissions) may be directly committed without first posing the submission to the mailing list. This goes for submissions by associates who are unaffiliated with the project, private correspondence to a committer, and third party open source code which is otherwise compatible with the Apache Software License. Where the project's policy is review-then-commit, there truly is no change to their current practice. All of the above cases are subject to review first on the mailing list. I believe the policy would directly address not only concerns w.r.t. the Heraldry project, but several prior issues and those that will still pop up over the horizon. Votes? +1 here. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Incubating Project Policy
James Margaris wrote: -1 from me. (If I even have a vote...) Although only ASF members/Incubator PMC votes are 'counted', yes everyone here has a voice - we do appreciate everyone's input. So should every podling. If I want to check in some third party code with a proper license, I don't really see the difference between checking it in directly vs. posting it to Jira and then checking it in. Is there some sort of implied waiting period during which people review the Jira patches? Well, if you post someone elses code to Jira just to circumvent the proposed policy, you are violating the policy. Maybe I need to more precisely define the third party code in question; it's code which the poster to Jira or the mailing list authored, their self. I also don't see why this is a case to protect against. If the policy of the project is to allow third party open source code with a compatible license and the policy is also commit-then-review, what is the issue? It seems this erases the distinction between commit-then-review and review-then-commit. Well, there are many homes for open source code. There are few homes which operate in an ASF-style meritocracy. This policy essentially says yes, all Incubator code would be commit-by-author and then review, and commits of external code where the authors don't actually participate in the project would be review-then-commit. I don't think this is erasing the distinction though. The point to ASF projects is to have the authors participate in the project. Participating by proxy is generally unhealthy to building an ASF community. It appears to me that the system is basically working. The Heraldry project has some issues, people spotted them, now appropriate action is being taken. According to the documentation mentors are supposed to keep their eyes open for these sorts of problems. Yes, action is being taken. This proposal is one of my first proposed solutions to that specific case, but as I was writing the email with respect to Heraldry, I realized it was a more general case and a more generalized issue. I don't see how this addresses the Heraldry problems. If they want to do a massive commit of externally developed changes they would now post them as a patch first (or mailing list message) and then commit them instead of just committing them - the end result is the same no? No, because the other project folk can put the breaks on overly large patches, and ask the individual contributors to stop and make the submission something that's digestible. They can stop and discuss the wisdom of scope changes or creeping featurism. They can decide if the code will be maintained, or if it's nothing but a code dump. To me that is just transferring the problem, now instead of a massive commit of external stuff you get a massive email message with that same externally developed stuff in it. The problem is that a bunch of external development is going on while the mailing list is silent, and this doesn't address that. Yes - that's another issue. Permitting commits-by-proxy has partially led to this situation. Solve the roots of the issue, then address the immediate issues at hand. I don't think there is any great way to prevent this sort of thing other than make it clear that it won't be tolerated and encouraging vigilance from the project mentors. If you want to develop the wazzit feature for the wizbang podling, all on your own, over the next two months and come back with a huge new patch, I wouldn't debate that. If Joe comes to the list with the wazzit feature you wrote, and you are off on some other page, I'd be very doubtful that the wizbang podling is willing to own your wazzit code. What I find a bit disturbing about this Heraldry business and the Kabuki fiasco before it is the lack of any communication out of the project. I would expect explanations from multiple committers, promises to do better, pleas for clarification or something of the sort. Maybe I've missed it but the Heraldry community seems pretty silent. And you (and any incubator participant) are welcome to engage them on their mailing list. I'm looking at the roots of these issues to find some unwritten practices at httpd server, tomcat and other ASF projects which have helped to sustain and foster their efforts. The problem is that the members know what works, and why, and often we have trouble distilling them into bite-sized nuggets of wisdom. Our code is developed within the sphere of our ASF community. How to turn that into policies which encourage development on list and discourage the evolution of code in the shadows where there is no history? I think that contributor-by-proxy is a pretty good example of what we want to discourage. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
