Re: Re: About the package proposal interface

On 17 Aug 2003 at 13:36, David Grant wrote: > On Sunday 17 August 2003 11:22, Derick Rethans wrote: > > The problem that I see is that a lot > > of people vote +1 for either the idea, or because > > they-might-sometime-need-this-feature too. I think that's wrong. IMO > > packages should be useful for a large group of people before put > > into PEAR. So the question should be "Is this package useful for a > > large group of people?" instead of the current "Is this package cool > > or might it sometime be useful to me?". Think outside yourself > > people... > > I haven't been around the PEAR community very long, and I know you > have, so you can disregard my opinion if you choose, but shouldn't > PEAR be a home for any package that provides an easier way to carry > out a specific task? I'm not talking about applications, but rather > wrappers and interfaces on to protocols, file types, technologies, > etc. that might take a while to write by oneself. I think if you can make do a task easier / "in just two lines" this package is a candidate in my eyes. It needs to have well written code, a clear and future-wise interface and be universal / extendable. [-> see next comment on Net_Gopher] > There are some packages in PEAR that are unlikely to be used by a > "large group", for example, Net_Gopher (no disrespect to Sara Golemon, > it was plucked for the statistics page), but if it is useful for just > a small group of people then surely it is worth it? I envisage PEAR > as a place for relative newbies to PHP (or even more experienced > types) to visit if there is something they're going to do with a > protcol, file type or technology that they are unsure of how to > approach. Okay most people might not have a concrete need for this. But I think it's a generally available protocol. The "problem" that it isn't used today anymore that much doesn't directly mean it shouldn't find it's way into pear. If the package is good and if the developer is still ready to maintain it that's fine with me. Just a "release and forget" is surely something we can't accept. > What are you reservations about large numbers of packages? Quality? > Administration? Surely with a rock solid QA (volunteer here) and > administration process, PEAR can avoid becoming the trial and error > reputation of other script sites? Your opinion would be interesting. Having a "large number" just to say that this is "the largest package- archive" or something shouldn't be a goal. But to most people I talked to pear is known as a well-structured repository where you can find many solutions for a given / distinct problem. This way I think having e.g. Net_Gopher is okay. If somebody needs Gopher and finds a package in pear he can be assured that it has a clear interface, has high quality and will keep maintained / supported by the maintainer. When problems with a certain package arise and the maintainer isn't available anymore surely we have a problem as the whole pear- community. But looking e.g. at Debian I think the concept of responsible "maintainers" for a package works good - and even better in pear! We should always think if the same task can be done with an already existing package, if the task of a package can be structured more universal or if several functions could be handled by other packages that already solve this problem (-> dependencies). And we shouldn't submit "trivial" packages. But as with Stream_Var I don't see a problem why this helpful and well done package shouldn't find it's way into pear. Just my 0.02 Euros. Stefan