Re: why creating "teams", "cores" and "groups" won't work this time, either

Ian Warner wrote: > LOL > > Doesnt this duel confound the point Scott was making initially. > > Who actually says YES - Scott that is a great idea run with it, or NO > stop wasting yours and everybodies elses time ?? > > If we are going to have a group created please make it one where people > have the power to say YES and in a timely manner, the trouble is it > takes too long to get a spark lit, most of the time you are left waiting > like a lemon with a sour taste brewing. > > I havent got PEPr permissions and will not get them for just wanting to > start ideas, I.e. I really liked the competition idea to get the site > and concepts looked at by NON-PEAR people, I thought this was a > no-brainer - Bertrand disagreed and the idea seems to have been shelved. > The trouble is I cant just go ahead and do this as who is to say the > winner's ideas will be implemented, probably be a 6 month discussion as > to what colour to go for. pearweb code is avalaible in CVS and as greg mentionned it needs major refactoring. You're welcome to makep patches available. > My company has currently hacked nearly every Package we use, we have > multiple extensions for quickforms, templates, paging DO etc. I would > submit more patches but they just dont seem to get a response, so why > waste my time really. I must apologise to Markus Tacker he let me into > his Google Map Trac system almost instantly on a new branch, but the > project I was doing with that got canned, so I havent helped as much as > I could, but when time permits I would still like the opportunity to do > that and I think that is still there. > > You know what would be cool is if I could just branch the package and > then implement in PEAR also, the owner of the package could then see the > this and no work is done except following a set branch if they choose. > > I reckon OPEN PEAR up to allow people to do this. I see so many packages > where Coding Standards are not even applied - how they ever got past > this is a wonder, I thought this was one of the main issues PEAR stood for. True, there are a lot of files and going through them by hand is not realistic. However there is now CodeSniffer which could be applied before a stable release... > Is PEAR elitist seems to be a common question, but only a few know the > answer :) > > Scott Mattocks wrote: >> Alexey Borzov wrote: >>> >>> Let's clarify here: QA team is expected to make changes to the >>> package without package maintainers' approval? >> >> From the Wiki page: >> "a) get the maintainer to fix them in a timely manner b) fix them >> themselves or c) find a new maintainer willing to fix the issues" >> >> I fully expect the QA team would proceed down the that list in order. >> >>> >>>> lack of ability, >>> >>> Forming of QA team will magically raise the ability of its members? >> >> The members of the QA team (whose responsibility it is to fix bugs) >> hopefully will have the ability to dive into code and figure out how >> it works. If they don't have that ability, then we as a community did >> a pretty poor job when casting votes. >> >>> >>>> lack of understanding of a package, >>> >>> Forming of QA team will magically improve understanding of packages >>> among its members? >>> >> >> The members of the QA team should be able to wrap their minds around >> pretty much any package. If they don't have that ability, then we as a >> community did a pretty poor job when casting votes. >> >>>> or pride. >>> >>> Don't quite get it, please clarify. >> >> Some people refuse to fix bugs because they refuse to admit they made >> a mistake. We are all guilty of it at times. >> >>> >>> Or maybe because these guidelines are not needed by anyone? You know >>> the open source motto of "scratching one's own itch"? >> >> If they weren't needed we wouldn't have large discussions about >> whether or not protected member vars should be prefixed with '_'. Are >> you really saying that we don't need a coding standard that stays >> up-to-date? >> >>> >>>> The QA group is designed to fix the declining level of quality in >>>> PEAR packages. >>> >>> Oh, so this level is declining? Undoubtedly you have at least *some* >>> facts to back up this statement? >> >> I would say that the percentage of proposals that actually make it >> through to the voting phase is an indication of the declining level of >> quality. We get a bunch of almost implemented ideas that just >> stagnate. I'd also point to the number of package that never make it >> to a stable release as another indicator of low quality. I also think >> that the number of bugs that have been open for over three months is >> an indicator of declining quality. If you think open for only three >> months is too short of a time period, how about open for six months or >> over a year? None of those numbers are going down. >> >>> >>>>> 2) Can the problems be solved without creating the group. If the >>>>> answer is "yes" then use Occam's razor [2]. >>>> >>>> If it could, we wouldn't have these problems now, would we? >>> >>> We do have problems, but repeating past mistakes is the wrong answer. >>> >> >> And just giving up is the answer? I am trying to build on what worked >> before while fixing the things that didn't. >> >> What is your plan for resolving these issues? >> >> Thanks, >> Scott >> >