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

Hello Helgi, From Tuesday, November 9, 2004, 7:11:19 PM, you wrote: HЮ> First of what is RFE, and voting on bugs, lets not get to pushy here, HЮ> PEAR QA is not intended to be following up on every bit of bug report, HЮ> only those regarding QA or are a big problem, with the color stuff, have HЮ> you have looked at the web interface as cvs.php.net ? it offers that. So, you propose me to vote on a PHP website for PEAR bugs? I don't know what QA is and I've expressed my opinion from reading RFC on the site. It is got to be so pushy because I still think QA politics is wrong and it infringes upon developers's interests. Even if it is not in reality - there is nothing to prove that. You've already read my previous letters and know what I think and why. Every new developer can think this way if he don't believe in human trust anymore and if he cares about the work he has done. HЮ> fresh bug reports, well you just have to check the bug system once in a HЮ> while :) RSS is maybe something we'll do, for each bug report and also HЮ> per package/category, subscribing to already reported bugs is also a HЮ> option I'm looking into. "Maybe", "You may do it like others do", "I don't need it", "I also want it" - is that a solution? All these answers are different ways to skip the problem. Then who should not skip them? Most will answer - QA, but you agree that QA don't have enough time, they mustn't process every bit of request, so let's just forget about it. Is that right? I not trying to state, that the problem is not only in QA, but I rather to say that QA is not that it is now. QA is not some people with unlimited access, but the way all developers collaborate. And it is the work of QA to look forward and make this collaboration productive on their own, to propose developers new ideas, to awake their interest in PEAR and know what developers want. From RFC I've got another idea. That's not a QA and shouldn't be called so. HЮ> Useless mailinglist, that's maybe to much to say that, but regarding HЮ> getting mail once a month, have you looked at HЮ> http://www.php-mag.net/itr/psecom,id,207,nodeid,207.html Aaron is doing HЮ> a great job there. Don't you think, that developers here are somewhat inactive? How do you think - why? If PEAR is so organized structure to have a QA, then why developers should read about PEAR from other sources? Think about many developers, who don't know about this link and never will know about it if not your letter. How many just don't have time to follow this thread, but interested in this information? >> Do other developers want it? Should they be subscribed to QA to >> discuss these questions? HЮ> If not subscribed, then they should asked to be CC'ed for the issues HЮ> they want, i.e. if they notice a interesting discussion on the QA ML, HЮ> they can ask people to include them in the discussion, like it has been HЮ> said before, QA things should stay on the QA ML, else, why should we HЮ> even have a QA ML if we are constantly discussing QA matters on PEAR-dev HЮ> ? I think the answer is that it isn't clear what are QA matters and why these matters are of QA? >> It will be dishonest to judge their work without them. =) HЮ> Well it is, but since I most of the time bug them about getting more HЮ> life into the QA team, plus I wrote the QA RFC, I'm very much aware of HЮ> what why the QA team isn't more alive then it is now. HЮ> But yeah they can speak up if they want to :) I think the problem is not in people but in idea that was dead from the start. QA must not be independent TEAM, but team, which works on well-known issues and that issues must be well-known by everybody who is willing to know. It is QA interest to make it convenient to recognize their work. Even if they've done something they doesn't show that they are trustworthy. If QA don't do anything then it's just hampering the progress just by it's existence. >> 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. HЮ> Woot ? No it's not a one SQL query, don't see how you get that out, I'm HЮ> also one of the webmasters of PEARweb, and I can't see any way of doing HЮ> any SQL magic to find out if a package is Orphan or not, because maybe a HЮ> package hasn't released anything for a long time because it's stable, or HЮ> that some package has a lot of bugs but the maintainer didn't get those HЮ> bug reports because of some techincal issues, that's why we need a bit HЮ> more orginized way of finding out orphaned package. I think everybody can participate. If they don't want then there must be a reason. Can QA be that reason? As for matter I think it is enough to check if a package hasn't released anything for a long time, has some bugreports and/or RFE's, also has very low download rate. After that if the package has developer who agrees that it isn't used anymore or it's functionality was superseded by other PEAR package it can be removed safely. Also there can be museum to contain packages which once was a part of PEAR with a copy of CVS repository and a short history - where, when, who, why. HЮ> Like said before, they haven't started anything real so this is a more HЮ> of a idea for the future you got here. Ideas for the future should have a proper place to find them in that future. For me QA must be formed de-facto by people who are doing something and not only by their votes. This is the only way it will work. >> 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? HЮ> I'm not understanding what you're getting at here, are you trying to HЮ> blame QA for something that isn't their business? No, I'm just trying to get answers on my questions and I don't want QA take over my work. HЮ> Can't see anyone restrict any access to anything, if anything, then QA HЮ> has a rather restricted RFC on doing things, because a dev actually has HЮ> to accept that QA does QA work on his package (unless it's a very HЮ> serious and outstanding bug that has been around for a long time, if I HЮ> remember correctly) so the power is still in developers hands. I don't want to accept QA will be working on my package and I'm against this, because I believe PEAR wasn't made for restricting things. Now if I want to release a package or to do something what is a QA issue I need to ask QA first. Is this not a restriction? HЮ> Like I said, I'm not understanding what your getting at. I want somebody to convince me of that QA is not the thing I've described. And I still think this QA is evil while PEAR was a good start and had a great potential. I can't get answers on most of my questions and I need to ask them again and again. How about to start QA RFC beta? If all of my questions receive answers it will be a good starting point and this ML is the only place to discuss it, since I'm willing to become a developer and really want to know what they think. >> 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. HЮ> Most of what problems ? HЮ> Can't see you mention any above, only feature request to make life of a HЮ> developer easier, i.e. the person has to do much less to get X thing, HЮ> but no real problems. I agree that these are not the real problems, but if even these local problems can't be solved then what QA we are speaking about? HЮ> Maybe you should consider a little what you're saying in this email and HЮ> in your previous, most of the time IMHO your talking about extra HЮ> features to pear.php.net which are unrelated to QA, which should have HЮ> been directed at the webmasters. Well, what is QA then? Fixing bugs/making releases - quote "If any QA related issues are found in a package that QA has not been granted permission to change without consulting the maintainer,the QA team will file a bug report. If the issue remains unresolved for 1 month (2+1+1 weeks; see below), QA may fix it themselves." That means - if I agreed QA will work with my package - QA will fix bugs/make release for me. If I not - QA will wait a month and will fix them anyway and it doesn't matter what is my point and why I haven't fixed them. Deleting Package releases - quote "The core QA team also has the permission to delete any release that might have any issues that have been found after the release, to reduce the effects of the problem." I don't want my releases to be deleted. I want to decide it myself where to fix and when to delete and think it is reasonable. If QA don't trust me then I don't have reasons to trust them. pearweb QA subsection - quote "The QA team also gets its own subsection on pearweb so people can more easily access QA material which is too dynamic or just related to the QA team own internal documentation purposes. There the QA will, for example, publish their latest decisions. Furthermore here the QA team will be able to provide interfaces to QA team services. For example, here the QA team could offer an interface for maintainers to configure the access rights they want to grant the QA." Where is it? I see some people with unlimited rights, but can't see their work except what they can delete my package, can fix minor bugs for me and make a local view, that I'm not a developer and all the good work made is made by QA. HЮ> But of course you have also had _some_ valid points, like the tracking HЮ> of QA and such, but you also have to realize that all that takes time to HЮ> code, work out and do in a right way, and frankly we don't have very HЮ> much time, you know work, maintaining package and all that, and then the HЮ> rest of the time we (at least I) try to use in enhancing pearweb. Then don't pretend to be QA. You don't do it and making PEAR better - you deserve my respect. I understand that you work on your own, but if you took responsibility to be called QA - be adequate. HЮ> Anyway you should sit down, think a little about what you've been saying HЮ> , and try to come up with something less negative on the people here HЮ> that are working for free, and thus don't have to waste more time then HЮ> they want on PEAR :) Ok. I must add everything I say is just how I see it. I have nothing negative on the people here, because I just don't know them. And I can't trust them because of the same reason. HЮ> If all those QA issues are so important to you, then I recommend to you HЮ> that you offer them your help to improve this situation, instead of HЮ> writing those rants ;) HЮ> Helps it always much appriciated in open source projects. I wouldn't mind to do so, But I still have the questions to be answered. Perhaps I'll rewrite them in a more obvious way when if there won't be any answer. HЮ> And as you might have noticed PEAR has been running rather well with out HЮ> any official QA team, maybe a little bit different to do it HЮ> "unofficially" but by all means PEAR doesn't have any less quality HЮ> packages and code even though the QA team isn't started (like you seemed HЮ> to have concluded in some of your previous posts) When why to have that QA? I would feel much better with knowledge that my package will not be deleted and nobody will mess with my code. Can you guarantee that? I haven't found the proof so far. HЮ> Anyway cheers and have a good evening Afraid to disappoint you, but it will be a long way before I'll get one. That's not because of PEAR, but still have an effect on the style of my letters. CU -- TiP