Re: Importing packages into CVS

Alexey, > That thread's contents are quite far from the "most people agreed that > having all packages in our CVS" claim you made in your post. So once > again, what's the point in doing this? - Source code is online browsable - Fixes can be done by QA easily, while that is not possible if the code is hosted on external sites. Fixes need to be done if the original author is not active anymore or does not react to inquries, which has happened too often in the past. - A package can be overtaken more easily. If author A hosts the code on his own server but retreats, ands B takes it over (maybe after some months, and there might not be the chance to get in contact with A) - where shall the code be hosted then? All of its history will be lost. The code would have to be imported into a VCS again, which is an unneccessary step. - The code in the released package is often old code, while the fresh code is on the developer's harddisk. If that crashed, code is lost again. - We can use our QA tools to check the status of packages: Which packages have documentation, which classes and methods in the package are documented, where the package does have problems. It might be possible to fetch all the tgz files each night, untar them and let the tools work on them, but that is really unconvenient. Further, it is a space problem: all the tgz files together are 1.8GiB, while a pear cvs checkout is 150MiB. Also, snapshot packages could be created automatically from cvs. -- Regards/Mit freundlichen Grüßen Christian Weiske

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc