Re: Importing packages into CVS

On Tue, 27 Mar 2007 20:50:30 -0400, Jon Parise wrote: >> >>>Do yo want to allow PEAR QA folks to commit changes to a package's >> >>>code? The code will become forked from the active development line. >> >>> >> Commiting to a fork could be a reasonable short term solution if the >> maintainer wasn't available for whatever reason, and an emergency bug >> fix was needed. > > While this is a valid case, I think it's exceptionally rare. If this is > the only true reason to mirror copies of active code on cvs.php.net, I > don't think it's worth the effort. If that ever happens then QA can import the package from a release and apply patches and do a release that way. >> >>>Do you want to archive a historic copy of the code, perhaps on a >> >>>per-release basis? pear.php.net already has a copy of the source >> >>>code on a per-release basis. >> >>> >> This code is available in the tarballs but not easily accessible since >> its all compressed, and has no tools associated with it. >> >> I think the biggest benefit is allowing for easy access to all the code >> by QA scripts. > > I'm inclined to disagree with this, as well. Sure, it's nice for QA to > 'cvs checkout pear/' to get all possible PEAR source code, but they > could also use a system that does: > > for package in allPackages: > extractPackageArchive() > results += analyzePackage() > cleanupPackage() QA shouldn't really be checking cvs unless the maintainer asks them, else just test releases, if there ever will be a QA auto rcs checker then it will just checkout from all relevant repos since it is a requirement to have a web/cli accessible repo if you want to be outside of the php cvs, shouldn't be hard to manage the info for each package if it comes to that. - Helgi