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.
