Re: Importing packages into CVS

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.