Re: Re: [PEPr] -1 for XML::XML_RPC2

Lukas Smith wrote:

Hans Lellelid wrote:

Daniel Convissor wrote:

Hi Sergio: On Tue, May 17, 2005 at 07:07:16PM +0100, Sergio Carvalho wrote:

Excuse me for the heads up, but you should refrain from voting then. I can't discuss any issues with you if you're scared by the noise alone.

My vote is completely appropriate. I don't want the package approved at this point due to unresolved issues. I've read the discussions. I just haven't looked over the source code.

I don't see any guidelines for the criteria for voting up or down a package on PEAR's site, so perhaps you are right that your vote is appropriate. However, it sounds more to me like you're just saying you voted -1 to just support the dissenting opinions of others on the list. That's great! -- I look forward to a day when all PEAR voting is done this way: with complete ignorance of the actual content of a proposed package.

Err, all he said is that some of the comments from people he respects sounded like valid criticism. As we want to ensure BC as much as possible its not necessarily wise to go +1 when in doubt.

BC? I don't think this package is aiming to provide BC for XML_RPC ... is it? I know that Daniel said that other people's opinions sounded valid, but those other people have their own votes. I'm suggesting that a -1 is a pretty strong statement to make without having even looked at the the sourcecode. Do we really disagree on that topic?

I have complete faith in Sergio & Greg to work out their differences in terms of the package design. I haven't used XML_RPC2, but I looked at the code & I think Sergio did a great job. It may not be the "best" design for PHP (admittedly I tend to favor the more Java-esque implementations too) but it was certainly good. I think that perhaps voting for the package was premature, as it seems like Sergio & Greg do have more to discuss; however, I respect both of them a great deal (& know that they respect each other) and am completely confident that they'll come up with a great implementation.

Yes, and there is no problem in doing another vote once the package is ready.

Voting -1 on this package instead of a conditional +1 (i.e. "great idea, but work it out!") is a pretty strong statement. I do think that voters

Err, he doesnt have time to check the packages. Therefore a +1 would be very wrong. However he did have time to check out the criticsm made on this list.

Right ... my point exactly. Those people expressing their opinions on the list had their own votes. I personally think that people should vote based on actual package review, not second-hand information & opinion. Perhaps PEAR Group doesn't feel that this is important.

have an obligation to actually look at the package code, *especially* if they're voting something down. Hopefully PEAR Group can add some guidelines to this end -- or perhaps they already have & I just didn't see them.

I hope the pear group does not add guidelines about this, and I am quite certain they will not.

Ok ... I know that you disagree with me by default :) but I'm really just trying to say that I think PEAR is better than this, that this seems like a popularity contest & personal problem rather than an objective evaluation of sourcecode. I believe packages should be accepted based on quality, usefulness, appropriateness, etc. I am simply suggesting that there should be some expectation that people voting on packages have looked at the code -- and, sure, have also followed discussions about them. I also would have thought that a guideline about this would be unnecessary; it seems rather obvious. Hans