Re: Re: PFC-RFC Update

Hi all! Sorry for spamming you, but my fu**ing OE seems to have deleted everything i wrote in my last post. Thats why you see my last post as just a fullqoute... Christian Stocker <chregu@bitflux.ch> artikulierte: > Hi Hi all! >> 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 understand the difference, but I'm still of the opinion that introducing PFC will divide PEAR in to classes of 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. +1 >> 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... Other system, same effect! > 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 ;) Thats not what i wanted. I think in "OpenSource" you're right, that the classification can be left by the maintainers themself. >> 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. I think this defines the sense of both ideas. To give another idea of my crazy brain: (*g*) What do you think about introducing PFCs, but doing that quietly? What I mean by this is, to introduce the "rating-program" you described above (has, has not), maybe defined in the package.xml and if a new release is signed to fullfill all needed issues to become a PFC the community will be informed (mail to the mailinglist?) and the described ensuring process will take place. The silent introduction should mean the following: A class which has been aproofed to be a valid PFC should IMHO become part of the PEAR package distributed with PHP (which are the core-packages in nower days). I know that this would blow up the distributed PEAR package, but when only installing the base of PEAR the users will be ashured to get only PFCs. This kind of system will introduce that kind of PFCs as you described it, but does not leave the other packages as "unstable". The user can have a look which parts of the PFC definiton are fullfilled and decide on their own weather to use them or not. I know that my ideas sound sometimes strange and are IMHO not well-formulated... I hope you'll forgive me about that, so flames please to /dev/null. Thanks for listening! Regards, Toby -- <?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);');} ?>