Re: PFC-RFC Update

On Tue, 2003-02-25 at 15:49, Paul Cooper wrote: > 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 That was the idea. No need for politics, just facts, which a package should conform to ;) But as you said, there are not hard facts, but rather soft facts. What is enough documentation? What is enough unit testing? What means "dependencies on non-standard extensions"? It needs someone, who can decide that and I think a reasonable PFC core group is the right place for that. > > - 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? PHP never used the even/odd versioninig-scheme, I don't think, we need that for PFC. Unstable = CVS and if someone wants to release a pre-package, he can certainly do it, but maybe outside of the pear-package-management system.. What's enough time? Yes, i had that in mind, what you proposed above. Except that it should be 2.0, if you break really BC (1.4 in your example) > 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? dunno ;) > 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. It was not my intention to put all of the work to the "core group". They should be able to quickly scan the 14 points (didn't count either) and take in account what others have said about it (especially the 2 peer-reviewers) > > > > > 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. that's a valid point. Automatic unittesting is more a way to ensure, nothing bad happens in the upload. If some things can't be tested, so be it. Better do some testing, than no testing. And multiple platform testing won't be possible anyway, or does pear/php have a windows/osx server at hand? > > 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. yes. I agree. It was more something coming out of the recent traffic on php-dev. It should not be in this RFC but maybe more in a general How-to-PEAR document, which applies to all packages, be it PFC or non-PFC. > > - 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. Right, I think, we can drop this point. I didn't have an opinion on this, therefore I marked it as "to be discussed" ;) > > - 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 ? Or can we put enough trust into the lead developers of those packages, that they will apply to the PFC standards forever? I think, PFC reapproval would only be needed for really major versions like 2.0, if at all. chregu