PEAR package retention policy

Hi,

As suggested by Greg in "Importing packages into
CVS" thread, I'm posting a list 
of changes that should be done to PEAR guidelines and
pearweb.

== Problem ==

Currently PEAR website allows package maintainers to delete
packages and package 
releases without any limitations whatsoever. This means that
a maintainer (or 
someone having his password) may delete a several-years-old
package with dozens 
of releases or delete any release of said package.

Such actions will affect all packages or applications
depending on the deleted 
package or requiring a specific deleted release of the
package.

== Proposed solution ==

In a nutshell, the proposed policy can be described as
"Whatever was released 
though pear.php.net, stays released".

The ability to delete a package release shall be limited to
releases not older 
than two weeks (*). Package maintainers are advised to use
this feature in the 
following cases only:
  - Broken package definition file
    - Missing required dependencies
    - Wrong dependencies
    - Missing files
    - etc.
  - Newly introduced severe bugs in stable releases (**)
  - Severe violations of PEAR's coding standards and
regulations
    - Incorrect names in public API
    - Incorrect package version

The ability to delete a package shall be limited to packages
with no releases.

= On "moved" packages =

As some developers may wish to move their development away
from PEAR's 
infrastructure, there should be a means to announce this
move (as opposed to 
declaring their packages unsupported), closing the
bug-tracker and giving a 
prominent link to a new location.


(*) The actual period is discussable.
(**) Releases of stability level lower than
"stable" are done for testing 
purposes and are expected to contain bugs.

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

Hi Alexey,

Looks great.  I only have one minor addendum:

Alexey Borzov wrote:
> Hi,
> 
> As suggested by Greg in "Importing packages into
CVS" thread, I'm
> posting a list of changes that should be done to PEAR
guidelines and
> pearweb.
> 
> == Problem ==
> 
> Currently PEAR website allows package maintainers to
delete packages and
> package releases without any limitations whatsoever.
This means that a
> maintainer (or someone having his password) may delete
a
> several-years-old package with dozens of releases or
delete any release
> of said package.
> 
> Such actions will affect all packages or applications
depending on the
> deleted package or requiring a specific deleted release
of the package.
> 
> == Proposed solution ==
> 
> In a nutshell, the proposed policy can be described as
"Whatever was
> released though pear.php.net, stays released".
> 
> The ability to delete a package release shall be
limited to releases not
> older than two weeks (*). Package maintainers are
advised to use this

after "two weeks" add ", although in special
circumstances, PEAR website
administrators may remove a package release after this time,
but only
after a public posting on the pear-webmaster list with at
least 1 week
for discussion."

> feature in the following cases only:
>  - Broken package definition file
>    - Missing required dependencies
>    - Wrong dependencies
>    - Missing files
>    - etc.
>  - Newly introduced severe bugs in stable releases
(**)
>  - Severe violations of PEAR's coding standards and
regulations
>    - Incorrect names in public API
>    - Incorrect package version
> 
> The ability to delete a package shall be limited to
packages with no
> releases.
> 
> = On "moved" packages =
> 
> As some developers may wish to move their development
away from PEAR's
> infrastructure, there should be a means to announce
this move (as
> opposed to declaring their packages unsupported),
closing the
> bug-tracker and giving a prominent link to a new
location.
> 
> 
> (*) The actual period is discussable.
> (**) Releases of stability level lower than
"stable" are done for
> testing purposes and are expected to contain bugs.

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

Sounds good to me, thumbs up.

- Helgi


On Thu, 05 Apr 2007 00:44:14 +0400, Alexey Borzov wrote:

> Hi,
> 
> As suggested by Greg in "Importing packages into
CVS" thread, I'm
> posting a list of changes that should be done to PEAR
guidelines and
> pearweb.
> 
> == Problem ==
> 
> Currently PEAR website allows package maintainers to
delete packages and
> package releases without any limitations whatsoever.
This means that a
> maintainer (or someone having his password) may delete
a
> several-years-old package with dozens of releases or
delete any release
> of said package.
> 
> Such actions will affect all packages or applications
depending on the
> deleted package or requiring a specific deleted release
of the package.
> 
> == Proposed solution ==
> 
> In a nutshell, the proposed policy can be described as
"Whatever was
> released though pear.php.net, stays released".
> 
> The ability to delete a package release shall be
limited to releases not
> older than two weeks (*). Package maintainers are
advised to use this
> feature in the following cases only:
>   - Broken package definition file
>     - Missing required dependencies
>     - Wrong dependencies
>     - Missing files
>     - etc.
>   - Newly introduced severe bugs in stable releases
(**) - Severe
>   violations of PEAR's coding standards and
regulations
>     - Incorrect names in public API
>     - Incorrect package version
> 
> The ability to delete a package shall be limited to
packages with no
> releases.
> 
> = On "moved" packages =
> 
> As some developers may wish to move their development
away from PEAR's
> infrastructure, there should be a means to announce
this move (as
> opposed to declaring their packages unsupported),
closing the
> bug-tracker and giving a prominent link to a new
location.
> 
> 
> (*) The actual period is discussable. (**) Releases of
stability level
> lower than "stable" are done for testing
purposes and are expected to
> contain bugs.

-- 
There are no stupid questions, only stupid people

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

There's perhaps a couple more points to discuss and add,
however so
far it looks very good 

+1

On 4/5/07, Helgi 辭rmar 辭rbj鰎nsson <dufuzphp.net> wrote:
> Sounds good to me, thumbs up.
>
> - Helgi
>
>
> On Thu, 05 Apr 2007 00:44:14 +0400, Alexey Borzov
wrote:
>
> > Hi,
> >
> > As suggested by Greg in "Importing packages
into CVS" thread, I'm
> > posting a list of changes that should be done to
PEAR guidelines and
> > pearweb.
> >
> > == Problem ==
> >
> > Currently PEAR website allows package maintainers
to delete packages and
> > package releases without any limitations
whatsoever. This means that a
> > maintainer (or someone having his password) may
delete a
> > several-years-old package with dozens of releases
or delete any release
> > of said package.
> >
> > Such actions will affect all packages or
applications depending on the
> > deleted package or requiring a specific deleted
release of the package.
> >
> > == Proposed solution ==
> >
> > In a nutshell, the proposed policy can be
described as "Whatever was
> > released though pear.php.net, stays
released".
> >
> > The ability to delete a package release shall be
limited to releases not
> > older than two weeks (*). Package maintainers are
advised to use this
> > feature in the following cases only:
> >   - Broken package definition file
> >     - Missing required dependencies
> >     - Wrong dependencies
> >     - Missing files
> >     - etc.
> >   - Newly introduced severe bugs in stable
releases (**) - Severe
> >   violations of PEAR's coding standards and
regulations
> >     - Incorrect names in public API
> >     - Incorrect package version
> >
> > The ability to delete a package shall be limited
to packages with no
> > releases.
> >
> > = On "moved" packages =
> >
> > As some developers may wish to move their
development away from PEAR's
> > infrastructure, there should be a means to
announce this move (as
> > opposed to declaring their packages unsupported),
closing the
> > bug-tracker and giving a prominent link to a new
location.
> >
> >
> > (*) The actual period is discussable. (**)
Releases of stability level
> > lower than "stable" are done for testing
purposes and are expected to
> > contain bugs.
>
> --
> There are no stupid questions, only stupid people
>
> --
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub
.php
>
>


-- 
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com
)
51.42.06.70.18

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

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

I +1 this as well. I don't see it noted down there, but you
should  
never be able to delete a release if any other package
depends on it  
(even if it's only a day old).

- --Joe


On Apr 5, 2007, at 10:34 AM, David Coallier wrote:

> There's perhaps a couple more points to discuss and
add, however so
> far it looks very good 
>
> +1
>
> On 4/5/07, Helgi 辭rmar 辭rbj鰎nsson <dufuzphp.net> wrote:
>> Sounds good to me, thumbs up.
>>
>> - Helgi
>>
>>
>> On Thu, 05 Apr 2007 00:44:14 +0400, Alexey Borzov
wrote:
>>
>> > Hi,
>> >
>> > As suggested by Greg in "Importing
packages into CVS" thread, I'm
>> > posting a list of changes that should be done
to PEAR guidelines  
>> and
>> > pearweb.
>> >
>> > == Problem ==
>> >
>> > Currently PEAR website allows package
maintainers to delete  
>> packages and
>> > package releases without any limitations
whatsoever. This means  
>> that a
>> > maintainer (or someone having his password)
may delete a
>> > several-years-old package with dozens of
releases or delete any  
>> release
>> > of said package.
>> >
>> > Such actions will affect all packages or
applications depending  
>> on the
>> > deleted package or requiring a specific
deleted release of the  
>> package.
>> >
>> > == Proposed solution ==
>> >
>> > In a nutshell, the proposed policy can be
described as "Whatever  
>> was
>> > released though pear.php.net, stays
released".
>> >
>> > The ability to delete a package release shall
be limited to  
>> releases not
>> > older than two weeks (*). Package maintainers
are advised to use  
>> this
>> > feature in the following cases only:
>> >   - Broken package definition file
>> >     - Missing required dependencies
>> >     - Wrong dependencies
>> >     - Missing files
>> >     - etc.
>> >   - Newly introduced severe bugs in stable
releases (**) - Severe
>> >   violations of PEAR's coding standards and
regulations
>> >     - Incorrect names in public API
>> >     - Incorrect package version
>> >
>> > The ability to delete a package shall be
limited to packages  
>> with no
>> > releases.
>> >
>> > = On "moved" packages =
>> >
>> > As some developers may wish to move their
development away from  
>> PEAR's
>> > infrastructure, there should be a means to
announce this move (as
>> > opposed to declaring their packages
unsupported), closing the
>> > bug-tracker and giving a prominent link to a
new location.
>> >
>> >
>> > (*) The actual period is discussable. (**)
Releases of stability  
>> level
>> > lower than "stable" are done for
testing purposes and are  
>> expected to
>> > contain bugs.
>>
>> --
>> There are no stupid questions, only stupid people
>>
>> --
>> PEAR Development Mailing List (http://pear.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub
.php
>>
>>
>
>
> -- 
> David Coallier,
> Founder & Software Architect,
> Agora Production (http://agoraproduction.com
)
> 51.42.06.70.18
>
> --
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub
.php
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGFTR7h0MUGpYY9OQRAgN+AJoCSnBSqznuL8cAfRrVuyRA48ecrgCg
pnc7
hJrnhvYwGvluoW8h/3Dz43I=
=ym6R
-----END PGP SIGNATURE-----

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

Alexey Borzov wrote:

> In a nutshell, the proposed policy can be described as
"Whatever was
> released though pear.php.net, stays released".

That is not compatible to any copyright law I know.

- Sebastian

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

Hi,

Sebastian Nohn wrote:
>> In a nutshell, the proposed policy can be described
as "Whatever was
>> released though pear.php.net, stays
released".
> 
> That is not compatible to any copyright law I know.

Well, Russian copyright law allows the author to recall the
published work *but* 
he must recover the users' losses including lost profits and
he must announce 
that recall beforehand.

I suspect that other copyright laws have similar
provisions.

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

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

Alexey Borzov wrote:

> Sebastian Nohn wrote:
>>> In a nutshell, the proposed policy can be
described as "Whatever was
>>> released though pear.php.net, stays
released".
>>
>> That is not compatible to any copyright law I
know.
> 
> Well, Russian copyright law allows the author to recall
the published
> work *but* he must recover the users' losses including
lost profits and
> he must announce that recall beforehand.
> 
> I suspect that other copyright laws have similar
provisions.

The german doesn't have any similar constraint.

Best regards,
  Sebastian Nohn
- --
Sebastian Nohn 路 Wolfstra脽e 29 路 53111 Bonn 路 Germany
+49-170-4718105 路 http://nohn.net/ 路
sebastiannohn.net
http://pgpkeys.pca.dfn
.de:11371/pks/lookup?op=get&fingerprint=on&search=0x
D47D55E0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFGFfiLsvwfldR9VeARAidVAKDkWFiqTLMJZqj/5sB+Ixf6KIwpiwCg
9eTq
+exUjNbOprjt4m78jk4vTwo=
=mQ2m
-----END PGP SIGNATURE-----

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

Sebastian Nohn wrote:
> Alexey Borzov wrote:
> 
>> In a nutshell, the proposed policy can be described
as "Whatever was
>> released though pear.php.net, stays
released".
> 
> That is not compatible to any copyright law I know.

Hi Sebastian,

Although I doubt there will ever be such a problem, should
an author
wish to withdraw sources, we can simply "fork" it
because (as you
recall) open source allows derived works.

No problem here.

Greg

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

Sebastian Nohn wrote:
> Alexey Borzov wrote:
> 
>> In a nutshell, the proposed policy can be described
as "Whatever was
>> released though pear.php.net, stays
released".
> 
> That is not compatible to any copyright law I know.

err .. its open source code .. *we* have a license ..

regards,
Lukas

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