Re: Importing packages into CVS

Alexey Borzov wrote:
> Hi,
> 
> Christian Weiske wrote:
>> After it seems that most people agreed that having
all packages in our
>> CVS, I would like to do the work and import every
version of every
>> package currently not in PEAR CVS into CVS.
>>
> 
> Let me give a more verbose version of my attitude to
this particular idea.
> 
> The *real* problem we had is disappearing releases:
this bites me
> directly, since my HTML_Template_Sigma package uses old
PHPUnit for its
> unit testing needs. Thus without old PHPUnit package on
PEAR website
> these tests cannot be run at all. Of course I can redo
them for current
> PHPUnit, but it is a bit stupid to require a PHP 5.2+
package for
> testing of PHP 4 one.
> 
> Now, is your "solution" helping at all? No,
'cause there still won't be
> any PHPUnit package and person wishing to test
HTML_Template_Sigma will
> need to checkout PHPUnit from CVS and jump through a
number of hoops to
> install / use it.
> 
> On the other hand, if PHPUnit releases *were* present
on PEAR website,
> anyone wishing to have them in CVS would be able to
import them to
> whatever CVS he likes.
> 
> So "just mirroring the releases" helps
nothing at all, *if* we prevent
> disappearing packages in the future. If we aren't
"just mirroring" but
> require using PHP CVS service, then this idea should go
through a more
> formal channel (like, RFC) rather than "it seems
that most people
> agreed". You'd be surprised on the number of
changes you'd have to make
> until there will be a real agreement.

Hi Alexey and company,

First, everyone has raised very good objections to the
original
proposals, and I think we can resolve this quite easily by
NOT touching
packages like the Horde packages.  I'm sorry the original
proposal blew
up, I'll take the blame/heat entirely for peoples concerns.

I think that there is a way to solve the issue that is
bothering me and
the one bothering Alexey, let me elaborate below.

I see two separate issues:

1) disappearing releases
2) orphaned packages that do not have CVS at cvs.php.net

There is no way to prevent disappearing packages at all.  As
it stands,
someone will have to take the time to reconstruct the
PHPUnit package
from CVS.  It will probably have to be me since no one else
has stepped
forward.  Let's just say I have the patience to do this kind
of bullshit
once in my life.  Imagine what would happen if the PHPUnit
package were
*not* hosted at cvs.php.net.  Reconstructing releases would
be quite
literally impossible.

One solution is to save a copy of all deleted releases
"just in case."
This is impractical for many reasons, but if any of you have
a better
suggestion I would love to hear it.

As for orphaned packages, this is far simpler: if the
package is not
maintained, and the RCS is external or non-existent, there
is no other
alternative, development is essentially over unless it is
imported into
cvs.php.net.

To resolve the issues raised on both sides of the fence, can
we take the
following steps:

If a package is unmaintained, its code must be imported into
CVS at
cvs.php.net so that another maintainer can take over the
lead role, and
QA releases can be made until that point in time when a new
maintainer
steps forward

If a package is maintained, no changes will be made to
anything.

If a maintainer decides to move a package out of
pear.php.net, the
package must be forked and added to cvs.php.net, and all old
releases
will not be deleted from pear.php.net.

Specifically, packages mentioned by Chuck in his first email
that are
maintained at Horde are not in any real danger of being
unmaintained,
and so would not have to worry about a thing unless Horde
decides to
drop them, and then there would be no hard feelings having
them imported
since Horde would no longer want to maintain them (do I have
this idea
right in my head?).

Does this satisfy everyone's worries?  I'm most concerned
with #2, #1 is
anomalous to PHPUnit, most packages just end not with a bang
but with a
whimper.

I'd really like to see the unmaintained packages available
for adoption.
 As I understand it, that is the primary goal of this new
thing.

Thanks,
Greg

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

On Wed Mar 28, 2007 at 12:1400AM -0500, Gregory Beaver
wrote:
> There is no way to prevent disappearing packages at
all.  As it stands,
> someone will have to take the time to reconstruct the
PHPUnit package
> from CVS.  It will probably have to be me since no one
else has stepped
> forward.  Let's just say I have the patience to do this
kind of bullshit
> once in my life.  Imagine what would happen if the
PHPUnit package were
> *not* hosted at cvs.php.net.  Reconstructing releases
would be quite
> literally impossible.

FYI, the .tar files for all PHPUnit releases ever still
reside on
pear.php.net.

- Martin

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

Hi,

Gregory Beaver wrote:
> First, everyone has raised very good objections to the
original
> proposals, and I think we can resolve this quite easily
by NOT touching
> packages like the Horde packages.  I'm sorry the
original proposal blew
> up, I'll take the blame/heat entirely for peoples
concerns.
> 
> I think that there is a way to solve the issue that is
bothering me and
> the one bothering Alexey, let me elaborate below.
> 
> I see two separate issues:
> 
> 1) disappearing releases
> 2) orphaned packages that do not have CVS at
cvs.php.net
> 
> There is no way to prevent disappearing packages at
all.  As it stands,
> someone will have to take the time to reconstruct the
PHPUnit package
> from CVS.  It will probably have to be me since no one
else has stepped
> forward.  Let's just say I have the patience to do this
kind of bullshit
> once in my life.  Imagine what would happen if the
PHPUnit package were
> *not* hosted at cvs.php.net.  Reconstructing releases
would be quite
> literally impossible.

Well, there is a way... Right now, if I go to HTML_QuickForm
homepage, I see big 
nice "Delete" button pointing to
package-delete.php script. Said script also has 
the following nice comment inside:
     // XXX: Implement backup functionality
     // make_backup($_GET['id']);
while implementing backup functionality may be a nice
improvement, why is this 
"Delete" button here in the first place?! Why
would someone want to delete the 
package that exists there for several years and has dozens
of releases? The same 
goes for delete buttons on package-edit.php form, which
allow deleting releases 
several years old.

My suggestion is to give a developer some limited time for
pulling the release 
(like a week, two weeks at most) since the problems
warranting said pull are 
usually quite obvious. And let's remove that
"Delete" button except for the 
packages that don't yet have any releases. Our main goal is
to ensure that 
whatever was released via PEAR stays there.

Of course deleting the packages will still be possible with
the help of the 
admin, but I hope our admins learned that lesson already.


So what I propose is writing guidelines for deleting
packages / releases and 
making changes to pearweb to enforce these.

cvs.php.net may be of some help, but consider the wonders of
"cvs admin -o" 
command. A person *really* dedicated to taking his ball and
going home can use 
this as a nice addition to clicking that "Delete"
buttons.

> One solution is to save a copy of all deleted releases
"just in case."
> This is impractical for many reasons, but if any of you
have a better
> suggestion I would love to hear it.
> 
> As for orphaned packages, this is far simpler: if the
package is not
> maintained, and the RCS is external or non-existent,
there is no other
> alternative, development is essentially over unless it
is imported into
> cvs.php.net.

Well, I think you are putting a proverbial cart before the
horse here. If a 
person comes up wishing to restart development, it is up to
him whether to 
import into PEAR CVS or some other SCM (I tend to agree with
Helgi's view on 
requirements for such SCM).

The same goes for QA releases, find the QA engineer first,
then he imports the 
code to PHP CVS.

> To resolve the issues raised on both sides of the
fence, can we take the
> following steps:
> 
> If a package is unmaintained, its code must be imported
into CVS at
> cvs.php.net so that another maintainer can take over
the lead role, and
> QA releases can be made until that point in time when a
new maintainer
> steps forward
> 
> If a package is maintained, no changes will be made to
anything.
> 
> If a maintainer decides to move a package out of
pear.php.net, the
> package must be forked and added to cvs.php.net, and
all old releases
> will not be deleted from pear.php.net.
> 
> Specifically, packages mentioned by Chuck in his first
email that are
> maintained at Horde are not in any real danger of being
unmaintained,
> and so would not have to worry about a thing unless
Horde decides to
> drop them, and then there would be no hard feelings
having them imported
> since Horde would no longer want to maintain them (do I
have this idea
> right in my head?).
> 
> Does this satisfy everyone's worries?  I'm most
concerned with #2, #1 is
> anomalous to PHPUnit, most packages just end not with a
bang but with a
> whimper.
> 
> I'd really like to see the unmaintained packages
available for adoption.
>  As I understand it, that is the primary goal of this
new thing.

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