Hi, We need a policy on how new projects under the P5EE CVS come to be.
http://cvs.perl.org/cvsweb/p5ee/ I propose the following rule: If any group advocating a P5EE Variant decides (by whatever means within their group) that they need another project to support their variant, it should be welcomed into the CVS repository. The only rule is that it must be referenced as part of their P5EE Variant (not some random module with no relation to their formulation of P5EE). (Of course, it never hurts to get input from the whole list first, even if a vote is not required.) If there is little or no discussion on this matter, we will adopt this rule. If there are many opposing views, we'll call for a vote. Stephen RATIONALE We originally started with P5EEx P5EE in order to begin prototyping (P5EEx) for the One True P5EE Code Base ("P5EE"). This concept gave way to the new approach of P5EE being a place where diverse views on Enterprise Development in Perl may be expressed, developed, elaborated, and supported. http://archive.develooper.com/p5ee%40perl.org/msg01105.html http://archive.develooper.com/p5ee%40perl.org/msg01109.html http://www.officevision.com/pub/p5ee/ I explained that I would refactor my P5EEx::Blue into three distributions, App-Context, App-Repository, and App-Widget. (This is still ongoing, subject to interruptions from directly revenue-producing work.) ;-) These were to become additional projects in the P5EE CVS at perl.org. Furthermore, the projects in the P5EE CVS may be contradictory, as per the suggestion of Tatsuhiko Miyagawa to model the P5EE CVS after the Jakarta project. http://archive.develooper.com/p5ee%40perl.org/msg01102.html So I believe that it is not critical that the whole list agree (i.e. through a formal vote) on the creation of a new CVS project. Rather, what is important is that the CVS supports those who are actually willing to put forth and support a P5EE Variant.