Re: Re: !!! Net_SMTP v1.2.4 is broken - please remove urgently !!!

Stefan Neufeind wrote:

As such it seems to me like the best course of action is the following: We offer to package developers to take over release management for them. We only do this for packages where we feel we can actually QA. This means we have to know the package and/or it needs to have good docs and/or it needs to have a test suite.

Whoo ... Lukas, as I saw in the last weeks you, Pierre and several other people had much more work to do than they had time left. So do you think this is a wise idea? Imho there are several other pending things which should be done urgently to further improve QA. And I don't think that we do have the capacities for "offering a release management service" at the moment.

then we simply have to expect more from the authors in terms of test and docs. This will increase the barrier to entry as well as shorten the time to handle each release.

All packages that do this get the QA seal of approval, which is shown on whereever possible for each given package.

Is that really necessary? Is that of any use for the end-user? My experience is that if you make suggestions via private mail first most devs are really happy that you try to help improve their packages. And if they don't react or if a mass of devs need to be notified then even filing bugs including the improvement-suggestions normally are well-accepted. So imho we should try to concentrate on the actual work and try to improve the quality of PEAR with all our strength ... but not created another artificial "stamp" for labling a package as PEAR-approved.

Well alot of developers are interested in feedback on functionality, fewer are interested in QA feedback (just look at the bug database). We need to communicate this to the users and it can get a bit more "complex" then just looking at the bug database, since you cant just count the bugs. An average time to fix bugs could be better. But anyways if QA has a section where they can communicate the QA status of a package then developers will hopefully realize more how important it is for their users.

Side note: And what if a package is "approved" but there are still bugs that you didn't find? Then end-users might think that even the stamp is useless? Not a good idea imho.

nobody is perfect. if too many bugs slip through we have to improve our QA process. if we have a test suite then we can better judge, however note that test suites vary in quality as well. anyways we simply have to communicate the scope of our QA'ing.

The developer focuses on creating a new release in CVS only and then comes to us for the actual release. We handle the release with more routine and by running the tests on the given release and then agree on making the release. This is essentially a cross breed of Jon's and my proposal. The idea would be that developers actually want us to add this seal of approval and therefore improve their docs, add tests and generally cooperate with us.

As outlined above: I don't think we have enough manpower and time to do that. We should invest our time in more important tasks ...

See above comments on how to limit the amounts of package that qualify as well as reducing the time needed to handle a release.

Those developers that dont cooperate with us for whatever reason dont need to be annoyed by us going crazy or "abusing" our powers. For those packages we will behave just like any PEAR user. If it breaks we mail pear-dev and/or file a bug report, but we dont remove releases or any such thing.

If the suggestions of PEAR QA are really quality-related, then I think PEAR should clarify that these "strong suggestions" need to be followed or a package might even be suspended from PEAR / given to a new maintainer if we only get ignorance as a feedback. However I don't think this is a normal behaviour and I believe / hope it will not occur.

I am quite shocked about the slow up take of the QA bug reports we made. Especially the get_class() issue is trivial to fix.

Unfortunately this email mixes two topics:

- The problem of ignorance to the things which are essential to maintain the quality of PEAR (urgent reactions) and the power of PEAR QA.

well my perception is that everybody wants quality to magically appear, however they are unwilling to accept the consequences, thats why I am suggesting to concentrate on the packages where the maintainer is willing to accept the concequences and not waste our time with the others. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07