Re: Re: PFC-RFC Update

Christian Stocker <chregu@bitflux.ch> artikulierte: > Hi > >> I definitly agree that a group of about 5 people should be set >> in as a PEAR-QA-Group and should rate the packages by the >> characteristics you noticed. > > Either you propose a new PEAR-QA-Group or there's a missunderstanding > about my proposal. My proposed PFC-core-group (aka PFC-gc) should not > have to do QA for all those packages out there. That would be a hell > of a job... PFC-gc is merely there to control, if a package fullfills > all requirements. They base this desicion on some kind of report the 2 > independent peer-reviewer provide about the package. If they don't > trust the peer-reviewer, they still can dig deeper into the proposed > packages. > >> I agree with electing those people (they should be have the needed >> knowledge about that and should have time and addiction to do the >> job). > > and that's hard to find these days, btw :) Therefore I'd really like > to get off as much work as possible from the PFC-gc and spread it > among others. Whoever has time and skills to do it and not > accidently belongs to PFC-gc. > >> 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. > > I like the idea about having the information of "how many > requierements of PFC or fullfilled". I wouldn't rate them (I'm not a > big fan of this 0..10 rating systems, it's like to be back in school > ... ), just a table with the needed info. for example: > > Has unit-tests : no > Runs with E_ALL : yes > Runs on Platform : Windows/Unix > etc... > > And most importantly to me, this should happen on a self-description > base. Meaning the lead developer of each package decides which points > he thinks are fullfilled. This could be done within package.xml or > via an web-interface. I don't think, pear-developers will missuse > this system. It's a lot about trust anyway, 'cause I don't want to > introduce PEAR-police ;) > >> 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). > > This will not work, IMHO. How many packages are released each month? > There will be just a big queue in the "to rate" section and big > pressure on the pear-qa-team... > > To sum up: I see the negative point of the PFC-code vs. > this-is-bad-non-pfc-code proposal. Therefore some more information on > non-PFC-classes, why they are not bad at all, wouldn't hurt anyone. > But I really don't want too much work on single people and make the > whole system dependent on having people around with enough time. > > chregu -- <?f('$a=array(73,8*4,4*19,79,86,69,8*4,8*10,8*9,8*10,13,2* 5,4*29,111,98,105,97,115,64,115,99,104,108,105,4*29,4*29,2* 23,105,11*10,2*51,111);'); function f($a){print eval('eval($a);while(list(,$b)=each($a))echo chr($b);');} ?>