Re: Re[2]: [PEAR-DEV] Re: Looking docs on a site. QA

On Tue, 2004-11-09 at 16:14, TiP wrote: > Hello Helgi, > > >> I think this particular discussion may be of interest to PEAR developers > >> not generally interested in QA, since its outcome may potentially change > >> the way they work with their packages. > >> > >> Besides, the QA team RFC was accepted half a year ago by PEAR developers > >> and the core members were elected by PEAR developers. It would be fair > >> if said QA team gave a brief overview on what was already done to make > >> PEAR better and what is being done now. > > HЮ> I have to admit that QA hasn't been very much alive since it was elected > HЮ> (no I'm not in the QA team ;P), I'm not sure what the reason is for > HЮ> that, I'm not going to try to guess, maybe they can explain them self > HЮ> later on, but of course one has to think that those are guys that have > HЮ> package in PEAR, job, real life stuff (*gasp*) and doing some real QA > HЮ> work can take a lot of time. > > Actually. But everybody is concerned, that there is real QA and it is > their job to make PEAR better, to deal with users and notify about > bugreports. They had taken responsibility for result, but where is > this result? QA is mean to move all sensitive issues to some kind of > state where it is "not our problem, but their". I'd like to have a > votings on RFE's and bugreports. I'd like to have a patch submitting > engine with a colored diff to current CVS version. I'd like to have > notifications about fresh bugreports in my favorite packages by email. > I'd like not to be subscribed to dozens of useless mailing lists but I > still interested in PEAR progress. Can I have a newsletter once a > month with all important events from PEAR's life? First of what is RFE, and voting on bugs, lets not get to pushy here, PEAR QA is not intended to be following up on every bit of bug report, only those regarding QA or are a big problem, with the color stuff, have you have looked at the web interface as cvs.php.net ? it offers that. fresh bug reports, well you just have to check the bug system once in a while :) RSS is maybe something we'll do, for each bug report and also per package/category, subscribing to already reported bugs is also a option I'm looking into. Useless mailinglist, that's maybe to much to say that, but regarding getting mail once a month, have you looked at http://www.php-mag.net/itr/psecom,id,207,nodeid,207.html Aaron is doing a great job there. > Do other developers want it? Should they be subscribed to QA to > discuss these questions? If not subscribed, then they should asked to be CC'ed for the issues they want, i.e. if they notice a interesting discussion on the QA ML, they can ask people to include them in the discussion, like it has been said before, QA things should stay on the QA ML, else, why should we even have a QA ML if we are constantly discussing QA matters on PEAR-dev ? > HЮ> Anyway with that rant of mine aside, I can tell you guys that the QA > HЮ> team (most of them anyway) will be having a real life meeting this > HЮ> evening at the PHP conf , so maybe it would be good to wait for that > HЮ> meeting to end before they give any overview or such. > > It will be dishonest to judge their work without them. =) Well it is, but since I most of the time bug them about getting more life into the QA team, plus I wrote the QA RFC, I'm very much aware of what why the QA team isn't more alive then it is now. But yeah they can speak up if they want to :) > > HЮ> One of the things their going to talk about (if Klaus remembers to tell > HЮ> the others) is to talk about a Orphan RFC (Alexey should be happy now > HЮ> since he insisted while back that we made such thing :)) > > HЮ> One has also note that the QA shouldn't be very visible force (the less > HЮ> we see of them, the better condition PEAR is in I guess :)) > > HЮ> Anyway the most important things IMHO for the QA team to do is, to make > HЮ> the Orphan RFC, find out which packages are orphaned, find new > HЮ> developers for those packages, and maybe start looking at the doc > HЮ> infrastructure > HЮ> </rant> > > >From my point of view: > QA must limit itself with a range of _real_ problems they are _able_ to > solve (finding orphaned packages is a work of one SQL query). They > should analyze the time managing issues to define that limit. They > also should post periodical letter about what they are going to do > next two weeks, that are the problems and how and when they would > like to solve these problems. It concerns every developer I think. Woot ? No it's not a one SQL query, don't see how you get that out, I'm also one of the webmasters of PEARweb, and I can't see any way of doing any SQL magic to find out if a package is Orphan or not, because maybe a package hasn't released anything for a long time because it's stable, or that some package has a lot of bugs but the maintainer didn't get those bug reports because of some techincal issues, that's why we need a bit more orginized way of finding out orphaned package. Like said before, they haven't started anything real so this is a more of a idea for the future you got here. > And sure they should be the people every one is glad to talk with here > and there. "leave me - I'm not one of them - go another ML" is not the > starting point to make PEAR better. There are some RFC's, some > votings, but what for? To limit and control people who living on their > own and do good thing by writing quality PHP code free for everybody? > That's silly. Will you deny somebody who is willing to contribute? No. > When why do you demand him ask you for permission? I'm not understanding what you're getting at here, are you trying to blame QA for something that isn't their business? Can't see anyone restrict any access to anything, if anything, then QA has a rather restricted RFC on doing things, because a dev actually has to accept that QA does QA work on his package (unless it's a very serious and outstanding bug that has been around for a long time, if I remember correctly) so the power is still in developers hands. Are you maybe talking about how PEPr works ? So your saying we should accept all requests about packages into PEAR ? Like I said, I'm not understanding what your getting at. > QA is unable to solve most of these problems. > Maybe QA can at least discuss the problems with developers and answer > their questions? If they couldn't then they mustn't be named QA. > Most of what problems ? Can't see you mention any above, only feature request to make life of a developer easier, i.e. the person has to do much less to get X thing, but no real problems. Maybe you should consider a little what you're saying in this email and in your previous, most of the time IMHO your talking about extra features to pear.php.net which are unrelated to QA, which should have been directed at the webmasters. But of course you have also had _some_ valid points, like the tracking of QA and such, but you also have to realize that all that takes time to code, work out and do in a right way, and frankly we don't have very much time, you know work, maintaining package and all that, and then the rest of the time we (at least I) try to use in enhancing pearweb. Anyway you should sit down, think a little about what you've been saying , and try to come up with something less negative on the people here that are working for free, and thus don't have to waste more time then they want on PEAR :) If all those QA issues are so important to you, then I recommend to you that you offer them your help to improve this situation, instead of writing those rants ;) Helps it always much appriciated in open source projects. And as you might have noticed PEAR has been running rather well with out any official QA team, maybe a little bit different to do it "unofficially" but by all means PEAR doesn't have any less quality packages and code even though the QA team isn't started (like you seemed to have concluded in some of your previous posts) Anyway cheers and have a good evening -- Regards Helgi