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

Hi folks, please excuse that I am just able to join this topic today - but I was ill yesterday and apparently I'm still ill now :-(( However, this topic is somewhat essential imho ... On 11 Mar 2004 at 15:40, Lukas Smith wrote: > Klaus Guenther wrote: > > > Pierre-Alain Joye <paj@pearfr.org> wrote: > > > >>On Thu, 11 Mar 2004 14:04:36 +0100 > >>klaus@capitalfocus.org (Klaus Guenther) wrote: > >> > >>>This is why QA needs karma! And please don't pretend that only a > >>>maintainer can pull a release... > >> > >>I do, at least for now. But we should be allowed to remove a > >>release. > > > > which is what I said... QA should be able to pull (remove) a release > > (I didn't say roll one). That's the only thing I means: Removing a release because it might break a lot of people's servers and apps if they just update a package and nothing works afterwards. It is not just "nice" to remove that broken release - but imho it's essential for PEAR to react to things like that soon. The release was not made out of any critical bug that was fixed - so taking it offline *immediately* and mailing Jon to fix everything else on his own would be enough. Imho no dev would punish anybody of QA just for taking a obviously broken release to save harm from many people using PEAR. And it's not that we need to save people so they don't loose their trust into that package but it might have a very bad effect on PEAR in general. We're all working hard to promote PEAR and to prove it's reliable. So once such a problem happens and it turns out we should be able to react within minutes. So I tried my best to solve the problem as soon as possible ... imho even a few minutes counted since they might be the reasons if we break another 50 servers or not. We have *all* agreed, and that's the only natural solution if you think it over carefully, that removing a broken release is essential. I was already involved in doing my best to help improve PEAR QA, tried it on several machines, I asked on IRC to double-check I didn't oversee anything ... and after all I asked that someone with enough karma (an PEAR admin) please remove that package immediately. What I got was reply from Derick saying that I'm not a maintainer and reply from Martin via IRC who agreed that the package was broken but that he didn't intend to do anything unless Jon or Chuck told him to do so (which might have taken another 24 hours or so, depending on how soon they read their mails). While I can understand that Martin wanted to try to avoid fumbling around in someone else's packages I can't understand the reactions I got. I was very releaved to see that after a while Lukas read my help- cries and took the chance of helping out. Note: I do not intend to accuse anybody personally because of not having done a thing. But removing a broken package is something vital. And since no karma for PEAR QA yet exists I can't understand why admins deny us to do what's best to maintain the quality of PEAR. <pathetic>But as written yesterday on IRC: Maybe it's just me who's being wrong and all other people here are the real genius. I can't understand those reactions ... but maybe I should even bother. My trust in the PEAR-community was heavily shaken yesterday.</pathetic> > ok lets keep this thread here. > pear-core is focused on infrastructure creation and therefore should > not be included in qa related things. If we ever need infrastructure we > can mail them :-) Alright. Then it was my fault - and I apologize for that. However, imho it was vital to reach *any* admin via *any* way as soon as possible. And I thought that pear-core are all the core guys of PEAR (pear-group, super-admins, ...) that have karma to help us out. But as it seems even the admins in charge didn't see the real necessity to act. I don't say that they should trust me or any "normal" person blindly. But since I was already involed in QA-work and since I also gave proof what went wrong and why they could have easily seen theirselves that the package was apparently wrong. So they didn't need to be "deep in the package" to see what's wrong. > Anyways maybe we do need to return to the topic of coming up with a > regulation of how QA should work in order to have other people also > able to remove releases. I didnt think we would have to do it this > often, but shockingly enough untested packages are released often. Totally agreed. > However the situation is not that dramatic since Pierre and I are > online alot and I am very willing to take the blame for fixing other > peoples mistakes if that improves the quality of packages. Anyways I > am on the verge of becoming disgruntled, but we better not go that > way. I am really starting to understand Jani more and more :-) We can rely on Pierre and Lukas, sure. And I must say that I was really relieved when Lukas confirmed to take over the job after all that nonsense-discussion that has started before. But this does not follow the sense of a PEAR QA-team that was discussed before. In a talk I had with Toby some time ago, he explained to me that the aim was to have several people (and even from separate timezones) that can react to really essential problems as soon as possible. As I explained above imho even a few minutes counted if some more servers got broken or not. And please note that I took enough time to make damn sure I reacted fully right. It's been shortly after the problem was discoved that Lukas took the job and removed the release. But imho we should rely too much on one or two people only. Again: I'm not talking about rolling a new release or fixing anything else. This was really not needed and would have been the wrong way. But removing a release to save other people from further harm was essential for PEAR in general. > We try to ensure quality, help developers fix their mistakes and in > return people call us "pedantic", "power hungry" etc. *sigh* Well, it's maybe a problem of the core group? Do they really trust the people at PEAR QA? As Lukas has already seen in the discussion it was commonly agreed that the release had to be removed soon. For everything else (looking over the code to help improve it, fixing whitespace-issues, ...) it's surely up to the developers if they want to allow us to directly fix this directly or if they prefer to have bugs filed. > 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. > 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. 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. > 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 ... > 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. For all cosmetic changes as outlined my experiences are that most devs are thankful for well-explained help that they are offered. 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. - The next steps to move PEAR QA forward. But I strongly hope that even the first topic will be further discussed and be brought to a clear end without silencing it because it's not wanted for discussion. Please comment (in public!) Stefan