Re: PFC-RFC Update

I think the RFC is great and agree wholeheartedly. On Tue, 2003-02-25 at 12:15, Christian Stocker wrote: [snip] > - PFC core group does not decide about which classes should go into PEAR. > This is still task of the whole PEAR community and the exact procedure > should be discussed in another RFC. PFC core group should be an > administrative counsil like the php-group and not make "political" > desicions. This wouldn't be in the spirit of php development. There shouldn't much need for politics or even 'decisions' because the way you have framed the requirements they are mostly facts, e.g. PFC only depend on PFC, follow PEAR CS, etc, so are (in general) either true or not. The main areas that are judgement are things like > - PFCs do not break BC without providing users enough time to adjust. A > well thought upgrade path should be provided. what is enough time? (Do you mean time or versions? e.g. 1.0.x are all BC, 1.2.x introduces new api but supports old settings by default, 1.4.x can drop old api and break 1.0 BC) - should standard versioning be part of the PFC, e.g. 1.even == stable, 1.odd == development? The BC requirement also feedback into the unit test requirement - that is there must be some way to test that new versions don't break BC so that this requirement can be tested. > - PFCs should keep the dependencies on non-standard extensions as low as > possible. There should always be a fallback, if the extension is not > available. This is could, at least in theory, be open to interpretation, although I can't think of a pertinant example. > - PFCs have to show some kind of stability (in API-sense) and should be > widely used. How does a developer or devel team demonstrate this? I'm not trying to argue against the 3 requirements above - I think they are all valid - but the easiest way for this to work is for a developer to know there are 14 requirements for PFC and how to pass them. So developer of Package X can post to pear-dev, with evidence of all requirements passed, or request for help with requirement n (e.g. help writing docs, testing on other platforms, etc). Then anyone interested can either test the requirements are indeed met or help to meet them. This will make life easier for the 'core group' too. > > Further Stuff: > -------------- > > - PFCs packages are signed with a PFC Key by the PFC core group (see > below). > > - PFCs are automatically tested on upload. If tests fail, the package will > not be published (multiple platform testing?) I don't think all testing can be automatic, e.g. for the unit tests for MDB you need to specify the dsn of the database system you're running the tests on. MDB and DB run on several database systems and they would the tests would need to pass on all databases supported. > To be discussed: > ---------------- > > - Concurrent Packages: The above point is not very clearly defined. From > my point of view, it would make sensde to not allow concurrent packages in > PFC. But then again, when is a package a concurrent package and when it's > a new one. Who decides that? > > - Who has the last saying? If some people want to do something this way > and some the other way, who decides? the lead developer(s)? the community? I don't see this as an issue for the specification of a PFC to deal with - bear in mind that given the requirements you've specified HTML_Template_IT wouldn't have been a PFC anyway (failed the unit test requirement for one - until Alexy wrote them). Conflict resolution is a general problem for PFC and non PFC classes alike. As I see it PFC is a stamp of a quality package where the user can expect a number quality features (14 currently if I can count), not a system for resolving disagreements between developers. > - Who can commit to PFCs? at the moment, everyone with a pear-cvs-account > can commit to every package. Shouldn't be this restricted for PFC classes? > Or is this getting to copmlicated for maintaining CVSROOT/avail. I don't see the need to be this strict. Development should just carry on as normal - it's the released version that need to be PFC compliant. > - If there is common approval of this RFC, what should be the next steps? 1 Developer posts compliance evidence / source / etc to pear-dev 2 We all test, reply, fix, or ignore as we see fit 3 'core group' coroborate the evidence 4 PFC failures are posted to pear-dev 5 Devs fix a resubmit 6 repeat 3 4 5 until PFC requirements passed 7 packages gains PFC icon in pear.php.net, docs are added to PFC section of docs, etc, etc I would think expecting developers to reapply for PFC for each version will be too much - however maybe reapply for each major version 1.2, 1.4, etc ? Paul > > > -- > nam...christian stocker adr...pflanzschulstr. 31, ch-8004 zurich > pho...+41 43 317 9984 www...http://blog.bitflux.ch > mob...+41 76 561 8860 ema...chregu@phant.ch > wor...+41 1 240 5670 gpg...0x5CE1DECB -- ----------------------------------------------------------------- Paul Cooper | Tel: 0121 331 7858 Software Manager | Fax: 0121 331 7859 Digital Media Centre | mailto:pgc@design4media.co.uk University of Central England | http://www.design4media.co.uk Birmingham, B4 7DX | -----------------------------------------------------------------