Re: Reliable software OR Is CPAN the sacred cow

[davorg]

This result in people stop thinking critically about CPAN, they believe is't goodness because it IS goodness, and that's all.

I don't believe that this is an accurate summary of anyone's views on CPAN (or, at least, anyone who has looked seriously at CPAN).

There is a _lot_ of code on CPAN. A lot of it is of very high quality and very useful. Some of it isn't. I don't think that's a problem with CPAN however, I see the low barrier to entry for CPAN as a feature. The Perl community has, in recent years, set up side projects to CPAN which allow users to see the "quality" of CPAN modules (as discussed by other users or determined by automated tests) and to give them more information on which to base their decision on whether or not to use a particular CPAN module.

We all realise that there are problems with some CPAN modules. There are almost certainly still bugs to find in pretty much every CPAN module. When you find one of these problems, you have a choice. You can mutter vaguely about the problem (as you've been doing on this site for the last few days) or you can help the author of the module to fix the problem and thereby help make the module better. There are a number of ways that you can help:

• Raise a bug report in RT (it would be nice if your bug included a failing test).
• Review the module on CPAN Ratings
• Annotate the POD to correct any error
• Join the module's mailing list (if one exists) and explain the problem
• Offer to fix the problem - provide a patch

This is open source software. Of course, you're free to use it (or not use it) as you wish. No-one is going to force you to contribute. But it would be really good if you could help out. You've made it clear recently that you're not happy with the quality of CPAN's email handling modules. But as far as I can see, you have done nothing to improve the situation. Yes, you say you've written your own implementation, but why haven't you released it? Or why haven't you contacted the Perl email project to offer your help? Or given them concrete examples of the way that their current modules fail? It's very easy to complain, but harder to do something constructive.

I don't believe that CPAN is a sacred cow. And I don't know anyone who does. I know that there's an awful lot of rubbish on CPAN. But I find rubbish there that I'd like to use then I don't waste time moaning about it, I do what I can to fix it. Why don't you do the same?

[powerman]

There is a _lot_ of code on CPAN. A lot of it is of very high quality and very useful.

Agreed! But high quality here isn't equal to reliable. For example, if your MTA will have a lot of features, high quality code and be very useful, but... in some rare cases (poweroff, badblocks in hard drive) it will damage your mailbox - NOT because of some small bug (this always can happens), BUT because it author doesn't try to think about this issue and concentrate on features instead (which in turn result in different internal architecture which make fixing these issues much harder or even impossible). And same is for security - high quality application developed without security in mind is suxx, sorry.

You can mutter vaguely about the problem (as you've been doing on this site for the last few days)

No, sorry, I'm not mutter vaguely about some features I need, which not exists in current CPAN software. I'm yell about lack of reliability and security in 99.9% of CPAN!

I'll be happy to send some bugreports or patches to existing modules, but I can't send patch which magically convert module developed without reliability and security in mind into reliable and secure module - it's much ease to develop own modules instead! (And this is what I'm doing - you can download a lot of my modules for free from my site.)

When I found reliable&secure enough software with some bugs I always send bugreports or patches. Last example of such software was MatrixSSL C library and Crypt::MatrixSSL perl interface for it. I've send several bugreports and patches to MatrixSSL, and found their developers responsible enough. And I've sent 12 patches to Crypt::MatrixSSL, but it author doesn't reviewed them yet (they was send 3 months ago, so probably I will fork this module if author doesn't reply in few weeks more). Here ChangeLog, if interested:

Read more... (12 kB)

[Asim]

I'll be happy to send some bugreports or patches to existing modules, but I can't send patch which magically convert module developed without reliability and security in mind into reliable and secure module - it's much ease to develop own modules instead! (And this is what I'm doing - you can download a lot of my modules for free from my site.)

Then I take back my commentary about bugpatching. Yet my core point remains -- if you have time to create modules, then either a) continue to help with bugpatching, b) put 'em on CPAN, so we can easily run and compare (and so others can test out your modules from the CPAN testing framework), and/or c) write actual documents to help us understand what you mean by reliable/secure coding.

Otherwise, we'll never know what the heck you're talking about, because all you've done is rant. And rants rarely get anything done, but we're all impressed with solid, well-documented code and coding ideas.