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