Re: Amsterdam meeting agenda
| From: | Lukas Smith | Date: | Sat, 10 Apr 2004 09:40:00 +0000 |
| Subject: | Re: Amsterdam meeting agenda | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-27379@lists.php.net to get a copy of this message | ||
Bertrand Mansion wrote:
<jon@php.net> wrote :this topic indirectly ties in with the work of the QA team. without public access to the current development version the QA team will have a hard time to help. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07On Sat, Apr 10, 2004 at 11:10:13AM +0200, Bertrand Mansion wrote:That's why I said .phps too. People are free to develop without using versioning, unfortunately, but when you are aiming a community of open-source developers, I think versioning is highly recommended. PEAR packages like Calendar have their own SourceForge project page and the code lives in CVS there. This way, the project actually gets double exposure (clever, isn't it ?). It is nice to have the choice. Still, IMO we shouldn't have to download the package in order to just browse the sources. That's maybe something that could be done in PEAR web too, convert the release .tar.gz to browsable code. Or maybe that's just a gadget ?- Where to find the source, online ? ------------------------------------------------------------ I hate it when the package I am interested in doesn't have its source in PEAR CVS. I have to download it, untar it, read the source in an IDE. I suggest that every packages should be available for browsing in CVS or Subversion repositories with online access. Or at least as .phps.Feel free to discuss this, but I don't think it's practical to require all PEAR source code to exist in a public repository. While it may be inconvenient for you to browse the source code because you need to download a distribution archive, it may be even more inconvenient for the package's developers to maintain their code in a public repository. I think the developers' preference should always take precedence here.