Re: Re: PFC-RFC Update

Tobias Schlitt wrote: > My Idea for rating the classes is to give them points (e.g. > stars) for matching some requirements. Initially every package > should get 1 point. When > fitting to the coding-standards it should get 2 points,... A > scale from 1 to > 5 is IMHO appropriate for that. Shouldn't all pear packages meet the CS? If there would be no CS, we'd get really sloppy coded packages -- they'd be very hard to understand and pretty difficult to maintain if the original developer decided to pass it on. Even with PFC, we shouldn't let pear become a scrapyard... As for rating packages in pear, who would do the rating? the developers could hardly be asked to rate their own code, and having the list vote on it isn't a good idea either. The QA team is only going to be responsible for PFC, all of which should be rated at 5, by your system. Many people, if they see points, will think that it has to do with popularity. So if there is a scale, there would have to be an individual symbol for each level, not stars or something like that. Personally, and I think this goes for many pear users, I don't come here for a quick fix, but rather for a well thought out building block that gives me the functionality that I need. If pear is thrown wide open to everyone, with lots of packages doing the same thing merely with different APIs, I don't think it will be of much use. If it goes this way, I'll switch to PFC for everything I can, and use pear modules as examples that I can use to help me build my own classes. If someone wants an application that they only need to configure, they should look elsewhere. And if they need code snippets, even the PHP manual provides that. I don't understand what pear would be if PFC is the only place where standards are enforced and new packages need to be approved. Pear needs to be kept to some quality standards, with PFC being the core suite for which the QA team would be responsible (i.e., they would require that the standards be met). I completely agree with the suggestions about documentation and unit tests, etc. That would turn PFC into a collection that really proves that PHP is second to none as a web application language, with a set of tools that are well documented and easy to use. > What about the way the classes are attempt to get rated? If > this 5 people in > QA-group have to rate every single release of a package they > will have a > huge amount of work to do. So, there should be a mechanism > implemented for > signing a new release as "to rate" or "same rate as last > release" (more or > less you should have the opportunity to mark a release as "to > rate" only > once per month or something else). Well, if diffs to the previous release are supplied to the QA team, it should make it much easier to evaluate. And of course, as long as BC isn't broken, the running the unit tests of the previous release should prove that nothing is broken. I don't know if all 5 need to examine each release. It probably would be sufficient if they examine every new class and then maybe 2 of 5 can approve of subsequent releases. With comprehensive unit tests and diffs it shouldn't be _all_ that time consuming -- provided the number of packages in PFC doesn't get out of hand. Another issue is CVS access... Do you really want everyone to have a CVS account? If pear is thrown wide open, account management will be rather difficult. Of course, I don't mean to suggest that CVS access would be misused, but if people are applying for an account, there must be a less time consuming way to get it done, without just having free automatic CVS registration which would be terrible. just my $0,02... Klaus