addition to PEAR2 coding standards that may be controversial

Hi all,

I moved dependency resolution to controversial changes,
pending further
review of the autoloading feature in PHP 6 (or 5.3 if
namespaces get
backported).

I've also added some text that more clearly redefines the
way that
packages would be accepted into PEAR2.  Currently, in order
to get a
package accepted into PEAR, the package must first undergo a
rigorous
examination, PEPr vote, and then after acceptance, no
further
requirements are made.  This results in many packages
"coasting" and
never reaching the "stable" label.  Due to
competing package rules, new
developers are required to adopt these packages if they wish
to write a
package that supports the same protocol, and must contact
existing
developers and jump through many hoops.  None of these rules
encourage
development or experimentation.

I'd like to propose we move the PEPr stage to the point at
which a
package is declared to be "beta" status.  Before
this point, as the
PEAR2 proposal states, a package is not publicly listed, but
is only
available on the website to other PEAR devs.  This would
mean that
interesting projects could host their codebase at
svn.pear.php.net and
develop freely, experimenting with impunity until they feel
it is time
to propose the package as beta.  At that time, the
collective would have
an opportunity to vote on the package, and decide whether it
is ready
for the prestige of "beta" and the public exposure
this would imply.  A
package marked as "beta" is expected to have a
stable API, meaning the
only changes would be for bug fixes prior to the stable
release.  As
such, the point of examination would be just prior to a
stable release,
where it allows us to truly enforce and encourage the
practices of
documentation and testing.  In addition, it will allow us to
get to know
new developers before we are locked into supporting their
packages in
perpetuity.

This will encourage much more innovation under PEAR's
umbrella, as well
as encourage more stable packages with better documentation
on the
public website.  Win-win.  Here is the actual language added
to the
proposal on ht
tp://wiki.pear.php.net/index.php/PEAR2_Standards

===Package acceptance into PEAR2===
Packages may begin development at svn.pear.php.net prior to
official
proposal as a new package for PEAR2.  A package is
considered to be
proposed when it reaches beta status, and must undergo full
review by a
collective.  PEPr is used by the collective to vote on
documentation, test suite conformance, and API.  If a user
objects to
the acceptance of a package by a collective, a formal
proposal to
PEAR Group through email to pear-groupphp.net can be used to call
a
general PEPr vote on a package's acceptance.


Are there any objection, or other considerations to take
into account?

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

consider this: you're a new developer and hacking around in
svn on your
soon-to-become beta project like a monkey and then the vote
is negative
and your work won't see the light of the day, at least not
on pear.

Ok, this is an extreme case and such a vote must have
reasons, too. But
this is the first thing which came into my mind after your
suggestion.

I agree that the current status needs improvement and I am
very
unfortunate that I cannot make a better suggestion now, but
maybe
someone else can.

In my mind I've this picture of the man, given the torch to
run and he
runs and runs but then isn't allowed to pass the goal ...

Maybe I'm exaggerating this point.

- - Markus

Gregory Beaver wrote:
> Hi all,
> 
> I moved dependency resolution to controversial changes,
pending further
> review of the autoloading feature in PHP 6 (or 5.3 if
namespaces get
> backported).
> 
> I've also added some text that more clearly redefines
the way that
> packages would be accepted into PEAR2.  Currently, in
order to get a
> package accepted into PEAR, the package must first
undergo a rigorous
> examination, PEPr vote, and then after acceptance, no
further
> requirements are made.  This results in many packages
"coasting" and
> never reaching the "stable" label.  Due to
competing package rules, new
> developers are required to adopt these packages if they
wish to write a
> package that supports the same protocol, and must
contact existing
> developers and jump through many hoops.  None of these
rules encourage
> development or experimentation.
> 
> I'd like to propose we move the PEPr stage to the point
at which a
> package is declared to be "beta" status. 
Before this point, as the
> PEAR2 proposal states, a package is not publicly
listed, but is only
> available on the website to other PEAR devs.  This
would mean that
> interesting projects could host their codebase at
svn.pear.php.net and
> develop freely, experimenting with impunity until they
feel it is time
> to propose the package as beta.  At that time, the
collective would have
> an opportunity to vote on the package, and decide
whether it is ready
> for the prestige of "beta" and the public
exposure this would imply.  A
> package marked as "beta" is expected to have
a stable API, meaning the
> only changes would be for bug fixes prior to the stable
release.  As
> such, the point of examination would be just prior to a
stable release,
> where it allows us to truly enforce and encourage the
practices of
> documentation and testing.  In addition, it will allow
us to get to know
> new developers before we are locked into supporting
their packages in
> perpetuity.
> 
> This will encourage much more innovation under PEAR's
umbrella, as well
> as encourage more stable packages with better
documentation on the
> public website.  Win-win.  Here is the actual language
added to the
> proposal on ht
tp://wiki.pear.php.net/index.php/PEAR2_Standards
> 
> ===Package acceptance into PEAR2===
> Packages may begin development at svn.pear.php.net
prior to official
> proposal as a new package for PEAR2.  A package is
considered to be
> proposed when it reaches beta status, and must undergo
full review by a
> collective.  PEPr is used by the collective to vote on
> documentation, test suite conformance, and API.  If a
user objects to
> the acceptance of a package by a collective, a formal
proposal to
> PEAR Group through email to pear-groupphp.net
can be used to call a
> general PEPr vote on a package's acceptance.
> 
> 
> Are there any objection, or other considerations to
take into account?
> 
> Greg
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFG4o6l1nS0RcInK9ARAsiMAJ938SDF5L3T1FQ/g562+zgCFEOYIQCe
IE7u
TJqRZ5tRH4AikphFw7/KDoE=
=6Vn8
-----END PGP SIGNATURE-----

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

While what you describe about teams/groups working together
to design 
and finalize a package is not unknown, it is the exception
rather than 
the rule.

Generally code is developed on a 'need' basis: eg. I need a
Capatcha 
generator to protect my site from blog spam - I write one,
then perhaps 
propose it to PEAR.

The reverse of this is
"Wouldn't it be good if PEAR had a Capatcha package,
let's design one 
for PEAR,and see if anyone uses it."

I would sumize that 99 out of 100 packages ever proposed
will be because 
of the driving needs of a  single developer, and are shared
via PEAR, on 
the off-chance they are useful to someone else..

Pepr in it's current place is pretty well suited to this, I
think if you 
are going to explore the idea of "collective
design", then you need to 
decide how that overlaps with the current situation, rather
than 
describe it as a replacement.

Regards
Alan



Gregory Beaver wrote:
> Hi all,
>
> I moved dependency resolution to controversial changes,
pending further
> review of the autoloading feature in PHP 6 (or 5.3 if
namespaces get
> backported).
>
> I've also added some text that more clearly redefines
the way that
> packages would be accepted into PEAR2.  Currently, in
order to get a
> package accepted into PEAR, the package must first
undergo a rigorous
> examination, PEPr vote, and then after acceptance, no
further
> requirements are made.  This results in many packages
"coasting" and
> never reaching the "stable" label.  Due to
competing package rules, new
> developers are required to adopt these packages if they
wish to write a
> package that supports the same protocol, and must
contact existing
> developers and jump through many hoops.  None of these
rules encourage
> development or experimentation.
>
> I'd like to propose we move the PEPr stage to the point
at which a
> package is declared to be "beta" status. 
Before this point, as the
> PEAR2 proposal states, a package is not publicly
listed, but is only
> available on the website to other PEAR devs.  This
would mean that
> interesting projects could host their codebase at
svn.pear.php.net and
> develop freely, experimenting with impunity until they
feel it is time
> to propose the package as beta.  At that time, the
collective would have
> an opportunity to vote on the package, and decide
whether it is ready
> for the prestige of "beta" and the public
exposure this would imply.  A
> package marked as "beta" is expected to have
a stable API, meaning the
> only changes would be for bug fixes prior to the stable
release.  As
> such, the point of examination would be just prior to a
stable release,
> where it allows us to truly enforce and encourage the
practices of
> documentation and testing.  In addition, it will allow
us to get to know
> new developers before we are locked into supporting
their packages in
> perpetuity.
>
> This will encourage much more innovation under PEAR's
umbrella, as well
> as encourage more stable packages with better
documentation on the
> public website.  Win-win.  Here is the actual language
added to the
> proposal on ht
tp://wiki.pear.php.net/index.php/PEAR2_Standards
>
> ===Package acceptance into PEAR2===
> Packages may begin development at svn.pear.php.net
prior to official
> proposal as a new package for PEAR2.  A package is
considered to be
> proposed when it reaches beta status, and must undergo
full review by a
> collective.  PEPr is used by the collective to vote on
> documentation, test suite conformance, and API.  If a
user objects to
> the acceptance of a package by a collective, a formal
proposal to
> PEAR Group through email to pear-groupphp.net
can be used to call a
> general PEPr vote on a package's acceptance.
>
>
> Are there any objection, or other considerations to
take into account?
>
> Greg
>
>   

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Markus Fischer wrote:
> Hi,
>
> consider this: you're a new developer and hacking
around in svn on your
> soon-to-become beta project like a monkey and then the
vote is negative
> and your work won't see the light of the day, at least
not on pear.
>
> Ok, this is an extreme case and such a vote must have
reasons, too. But
> this is the first thing which came into my mind after
your suggestion.
>
> I agree that the current status needs improvement and I
am very
> unfortunate that I cannot make a better suggestion now,
but maybe
> someone else can.
>
> In my mind I've this picture of the man, given the
torch to run and he
> runs and runs but then isn't allowed to pass the goal
...
>
> Maybe I'm exaggerating this point.
Hi,

After Alan and Markus's initial criticism, I revised the
language to this:


===Package acceptance into PEAR2===
Packages can be proposed for PEPr as new ideas or as
completed code. 
Development for new packages must be at svn.pear.php.net.
A package must undergo full review by a collective when
moving from
alpha to beta status, but it is expected that this review
will
be ongoing as development progresses to make the review a
smooth
process.  PEPr is used by the collective to vote on
documentation, test suite conformance, and API.

Does that look acceptable?

Now the only big change here is that packages can be
proposed as ideas
and started as development from scratch in svn.pear.php.net
in addition
to being proposed as fully fleshed-out code.  The whole of
PEAR still
votes on package acceptance as we do now, that part of my
changes was
dropped.  All of these proposals would require tweaking to
PEPr, but
that's a minor issue.

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Getting there = It needs to be laid out as bullet points,
there is alot 
of information in that single paragraph, It also needs
expanding  a little.


Packages can be proposed either as
a) A completed, or relatively complete package to Pepr
b) A concept, or proof of concept to
svn.pear.php.net/concepts [?? use a 
subdirectory/different repo for them ??]

For concept packages they should
= Be approved on the mailing list by??? before being
accepted into the 
concept directory
= Undergo a review [??what exactly does this mean?? = a Pepr
vote??] by 
the collective when going from Alpha to Beta??
= Pepr may be used by the collective to vote on package [??
at what 
point  - paragraph below is vauge - is a one vote needed for
API, docs 
etc.??]
= [At what point should the be put into the 'release
system']




> Hi,
>
> After Alan and Markus's initial criticism, I revised
the language to this:
>
>
> ===Package acceptance into PEAR2===
> Packages can be proposed for PEPr as new ideas or as
completed code. 
> Development for new packages must be at
svn.pear.php.net.
> A package must undergo full review by a collective when
moving from
> alpha to beta status, but it is expected that this
review will
> be ongoing as development progresses to make the review
a smooth
> process.  PEPr is used by the collective to vote on
> documentation, test suite conformance, and API.
>
> Does that look acceptable?
>
> Now the only big change here is that packages can be
proposed as ideas
> and started as development from scratch in
svn.pear.php.net in addition
> to being proposed as fully fleshed-out code.  The whole
of PEAR still
> votes on package acceptance as we do now, that part of
my changes was
> dropped.  All of these proposals would require tweaking
to PEPr, but
> that's a minor issue.
>
> Greg
>   

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Alan Knowles wrote:
> Getting there = It needs to be laid out as bullet
points, there is
> alot of information in that single paragraph, It also
needs expanding 
> a little.
>
>
> Packages can be proposed either as
> a) A completed, or relatively complete package to Pepr
> b) A concept, or proof of concept to
svn.pear.php.net/concepts [?? use
> a subdirectory/different repo for them ??]
>
> For concept packages they should
> = Be approved on the mailing list by??? before being
accepted into the
> concept directory
> = Undergo a review [??what exactly does this mean?? = a
Pepr vote??]
> by the collective when going from Alpha to Beta??
> = Pepr may be used by the collective to vote on package
[?? at what
> point  - paragraph below is vauge - is a one vote
needed for API, docs
> etc.??]
> = [At what point should the be put into the 'release
system'] 

How's this look:

===Package acceptance into PEAR2===
Packages can be proposed either as
1) A completed, or relatively complete package to Pepr
2) A concept, or proof-of-concept to
svn.pear.php.net/PEAR2/alpha

For proof-of-concept packages they should

* Post a public notice to the pear-dev mailing list stating
the
intention to begin development
* Request a new package be created on the pear.php.net
website
* Undergo a review by the collective (as defined in the
previous
section) when ready to move from alpha to beta stability
* Once the review is complete, the package developers may
request an
official vote by the collective on whether the package is
ready.  The
vote is conducted through PEPr.  Unsuccessful packages may
request a
second review after fixing issues noted by the collective.
* Successful packages may then move their development
directly from
svn.pear.php.net/PEAR2/alpha into svn.pear.php.net/PEAR2
using svn move

Here are the latest drafts:
ht
tp://wiki.pear.php.net/index.php/PEAR2_Standards
http://wiki.pear.php.net/index.php/Controversial_Changes



Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

<snip snip..> - see note on when a package is created
on pear website....
> How's this look:
>
> ===Package acceptance into PEAR2===
> Packages can be proposed either as
> 1) A completed, or relatively complete package to Pepr
> 2) A concept, or proof-of-concept to
svn.pear.php.net/PEAR2/alpha
>
> For proof-of-concept packages they should
>
> * Post a public notice to the pear-dev mailing list
stating the
> intention to begin development
> * Request a new package be created on the pear.php.net
website
>   
This was the concern - HTML_Template would probably have
fitted into 
this category, and never got off the ground really... - It
was never put 
into the website, correctly so... - Perhaps that means that
it should 
have stayed as a Pepr proposal, rather than registered as a
real package..

Thoughts?

Otherwise looks fine...

Regards
Alan
> * Undergo a review by the collective (as defined in the
previous
> section) when ready to move from alpha to beta
stability
> * Once the review is complete, the package developers
may request an
> official vote by the collective on whether the package
is ready.  The
> vote is conducted through PEPr.  Unsuccessful packages
may request a
> second review after fixing issues noted by the
collective.
> * Successful packages may then move their development
directly from
> svn.pear.php.net/PEAR2/alpha into
svn.pear.php.net/PEAR2 using svn move
>
> Here are the latest drafts:
> ht
tp://wiki.pear.php.net/index.php/PEAR2_Standards
> http://wiki.pear.php.net/index.php/Controversial_Changes

>
>
> Greg
>   

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php