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

Just let me say in opening here...EXPLETIVE DELETED! You're really making a mountain out of a molehill here. The QA team is *not* a secretive Illuminati type group. Look at the pear-dev and pear-general archives for when the QA team was being discussed there is a lot of discussion about it all. Now, to respond to some of your statements below. On Wed, 10 Nov 2004 22:25:38 +0200, TiP <tip@tut.by> wrote: > Hello Helgi, > > From Tuesday, November 9, 2004, 7:11:19 PM, you wrote: [snip] > 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. If you don't trust other people it's hard to be part of a community. PEAR is a community that existed long before this discussion. You have to start with trust, otherwise you'll never get anywhere. > > 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. 1) QA is about the quality of PEAR packages, not about website enhancements. It's not directly about the easiness or quality of support developers get with regards to PEAR. THe pear-dev list is for support of developers. QA makes sure that the quality of the code is upheld. This means (in my words) that they deal with long outstanding bugs, old packages, Backwards Compatibility (BC) and standards. This is pretty much laid out in the RFC and the accompanying discussions on the lists. (Devs, if I have this wrong, please correct me) 2) QA is not all powerful, although many of them do have pretty much unlimited rights. QA has a very limited purpose, as outlined above. The real "super users" are the PEAR Group, but they very rarely make unilateral decisions. Everything is discussed and announed on the lists. > 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? Are you offering to write summaries of the discussions? If that URL is too hard to find, it should be linked from the PEAR website (if it is already not). Take that up with PEARweb maintainers. > > >> 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? QA matters are those pertaining to the purpose of QA, as I outlined above. > > >> 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. If you're this worried about QA, go back and read the archives. QA is a team which was created because the DEVS on this list wanted a team to oversee QA issues. QA is handled, overall, by each individual dev. People (anyone) submits bugs to the bug system. The leads on the package take care of them. End of story. QA only gets involved if they see a major issue are are either authorized to make changes or have waited for a specified period for some kind of confirmation from the package dev(s). All of the QA members are members of this community. For you to simply mis-trust everyone because you're new here is a bit offensive, to be honest. > > >> 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. You just outlined EXACTLY what the QA team ALREADY IS. As I said before, the package devs take care of round one of QA problems. If that doesn't solve it, the user (or whoever) usually comes to the pear-general or dev list and posts a request for help there. If no one can get something done and something must be done, then QA steps in. > > 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 it was. The devs wanted it and so it was created. We use voting to be democratic. Otherwise *nothing* would ever happen. This community is too big to only do things on discussion for most things. We discuss and create RFCs, edit, and vote. The Exception RFC is a great example. > > >> 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? This is PEAR in general, not QA. The PEAR community has standards to make sure that the code works well, is maintainable, and is interoperable. You have to comply with PEAR's standards to contribue code to PEAR. We accept anyone's code as long as they're willing to follow standards, *none of which* is there just to make peoples' lives harder. It's all there for a reason. If you don't understand it, check the archives (it *has* been discussed before), then e-mail the list asking politely why it's there. [snip] > 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? This is *not* how QA works. You can edit your source code and check things into CVS whenever you want. If, however, you broke a standard (such as the versioning standards) or your release simply doesn't work or it breaks BC in a major way then QA *may* remove the release so that people don't upgrade to a broken version. You don't have to ask to release, except for the first one. Once you have a package you can do whatever you want *within the rules*. > 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. I hope I've answered you above. [snip] > 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. No, it matters what your point is. If it's an RFE, QA is not likely to take that up unless the package is abandoned. If it's a bug fix and QA can't contact you, they'll step in. If you deal with the bug (however it needs to be dealt with) then you'll never hear a peep from QA. > > 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. As stated above, QA will remove releases if they don't conform to standards. They *will* contact you about it, probably before the release is removed depending on the severity of the problem. If you hear about it and fix it first, QA won't step in. QA trusts you. They may remove it because *they* are there to make sure these things are dealt with in a timely manner. If you respond decently quickly, QA won't step in. If they do, they'll send you an e-mail telling you why. You can then fix it and re-release. QA works *with* you. > > 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. They don't have unlimited rights. Their actions are laid out as above. They *will* contact you before doing anything. If you *don't respond* they will step in. They *will not* fix minor bugs without at least trying to contact you. It's a huge no-no for ALL PEAR devs to touch another's CVS or package. It's only done when there is urgent need or the package has been abandoned. > > 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. He doesn't pretend to be QA. QA doesn't enhance pearweb. QA handles PEAR package code. See (way) above. > > 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. You must trust people in the community to be part of it. If you haven't been around long enough to trust us, wait until you do, then propose your package. > > 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. If you still see problems, please try to be constructive in your comments instead of just saying "I can't trust you". > > 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. Before QA it was not specified when this would happen. People got angry. Peoepl got frustrated. QA was created to show who's responsible and to have a plan of action laid out for these matters. Again, why the mistrust? QA isn't here to ake your life harder. It's here to make your life and the users of your package's lives easier. -- Justin Patrin