Module::Build and the PPM

[barbie]

Recently there was an upload to CPAN featuring a PPM of an already existing distribution. Due to the way new uploads are announced, the module got announced on the cpan-testers list, and consequently got tested. As it's a ppm distribution it contains only a blib/ directory of files. The result for cpan-testing where several UNKNOWN reports being sent to the author and the list.

Randy Kobes sent a mail to the list indicating that as a result of a recent upgrade to Module::Build, that this is likely to now happen quite a lot. As a result of an intriguing conversation with Randy over this, it raised a few points/questions in my mind.

1. Perhaps this isn't something that should be sent to CPAN, but to a PPM repository.
2. If this gets sent to CPAN and is not indexed (due to it only containing the blib/ directory), what happens when someone else has a regular distribution with the same name.
3. Why has Module::Build decided adding 'PPM-' to the beginning a good idea?
4. Why has Module::Build suddenly decided to affect CPAN without conferring with the module authors list, or the CPAN/PAUSE maintainers, or considering the bigger effects.
5. If PPMs are being sent to CPAN, perhaps we ought also include RPMs too.

Now there are whole lot of issues here, and many monks maybe already writing their retorts now. However, this is not intended as a flame incitement, but a starting point (seeing as no-one seems to have started one before) for further discussions. Let me clarify my thoughts further.

Point 1: CPAN is well established and there are generally three recommended ways to install using any part of CPAN. perl Makefile.PL, CPAN.pm or CPANPLUS.pm. Some also use Module::Build, but that's not currently as popular as the others. As such anyone trying to use either of those methods is not going to get an install from this distribution. This then affects how some may perceive CPAN. This is bad in my opinion.

Point 2: I can see the following both being uploaded to CPAN; A/AU/AUTHORX/PPM-Cool-Module-0.01.tar.gz and A/AU/AUTHORY/PPM-Cool-Module-0.01.tar.gz. Which one is the Module::Build generated ppm distribution? The answer will be in 02packages.details.txt.gz. Or you could just download and see what's in it.

Point 3: I might be off course here, but wouldn't it have been more wiser to have Cool-Module-0.01.ppm.tar.gz? Or even better to have Cool-Module-0.01.ppm, which would actually be a tarball including a .tar.gz and .ppd. This would then make it much better to spot what it was. I have often wonder why ActiveState never adopted something like that. Perhaps that's for PPM4.

Point 4: If you are likely to affect how CPAN is used, it would seem to me, that you should be at least be courteous to let the CPAN/PAUSE maintainers, and other authors, know about what you're planning. I haven't seen any such discussion either on the module-authors list or the authors list. Randy actually mentioned that there wasn't much discussion on the Module::Build list, which I am very surprised at. Now maybe it wasn't envisaged that these distributions would be put on CPAN, but I can't but feel it must have been something that the authors considered as part of the effects of the change.

Point 5: I personally would like to see a repository of RPMs of Perl distributions available, as here at work we are planning to recompile a whole host of distributions as non-threaded. It would be nice if we could just pick them off the shelf. Randy tells me there are some RPMs already on CPAN, but I haven't come across any, and am not convinced that CPAN is the place for them anyway.

Continuing Points 1 and 5 first. Perhaps now that there are so many PPM repositories available, is now the time that those with repositories start getting together and looking at replicating each other, much in the same way the CPAN mirrors work? As the CPAN mirror process has proved successful, a PPM and a Perl-only-RPM mirror network might be just the thing to further the great thing about Perl and CPAN networking. It would also mean that the few current servers that host high profile PPM packages (Template-Toolkit comes to mind, as even ActiveState don't carry it) might balance the load on each more evenly. Then if a mirror did go down, there are still several repositories still online. Now don't get me wrong this is a big task, and not one I would approach lightly. However, the fact that situations like this ppm distribution upload are beginning to occur, perhaps now is the time for PPM repository owners to get together.

Continuing Points 2, 3 and 4. I seem to be continually up against Module::Build, as I have had nothing but problems with the distribution, despite several of the London Perl Mongers claiming it to be the latest and greatest. Maybe its because I've only tried it on Windows, however, perl Makefile.PL/CPAN.pm/CPANPLUS.pm works fine on every Windows machine I've used. While I applaud the authors for trying to create a pure Perl build mechanism, I am also disappointed when they seemingly try too much, without appearing to think things through. Allowing Module::Build to create and probably install a ppm distribution is to their credit. However, the way they have gone about it, appears to me perhaps not the best choice.

I guess this all comes down to the following questions:

1. Are PPM/RPM repositories likely to happen or be a good idea?
2. Is Module::Build trying too hard?
3. If not, is it really going to take over from MakeMaker?

I'm particularly intrigued by the last two, as I am very reluctant to recommend this route of making/building/compiling a module to anyone at the moment.

[hardburn]

Are PPM/RPM repositories likely to happen or be a good idea?

IMHO, the CPAN repository should be as platform-agnostic as possible. Of course, things in the Win32:: namespace will rarely, if ever, be useful outside Windows. Even so, things on CPAN need to install the same way on a broad range of platforms.

There is an argument that fledgling package systems could make use of the CPAN mirrors instead of going to the trouble of setting up its own mirror system. For those people, I suggest looking at an article I wrote for the Linux Journal a while back on Using Debian Apt-get over Freenet. It makes use of Freenet's FProxy (a gateway that lets you use Freenet over HTTP) to allow any package management system that can support HTTP to use Freenet. The article is specific to Debian, but the approach could probably be generalized to almost any package manager with HTTP support.

(Note that I've stepped away from the Freenet project, so things might have changed since I wrote the article. However, I imagine FProxy is still there and the basic approach will still work.)

[eserte]

It's a common misconception that CPAN is a perl module repository. CPAN is really an everything-about-perl repository. There are some views to this repository and the most popular is the modules view (through CPAN.pm or http://search.cpan.org), but there is also a script directory (http://www.cpan.org/scripts/) and people put perl source and binary distributions or even perl-related emacs lisp files to CPAN.

It's OK for me if people want to put PPMs in their CPAN directory. What looks wrong with the Module-Build generated PPMs is the naming scheme. It should really be module-version-architecture-ppm.tgz or similar. Here are some naming examples of already existing PPMs:

ClearCase-Attache-0.01-PPM.zip
Allegro-0.02_0-ppm-MSWin32-x86-multi-thread-5.6.tar.gz.01-PPM.zip
ppm/Winamp-Control.tar.gz

[hardburn]

If there was a seperate area of CPAN set aside for PPMs, I wouldn't have a problem with it. However, everything that is in the modules section should not be a platform-specific package format. Opening up another section (or sub-section) for special package formats is a possibility.

Essentially, I belive anything in the modules section should have the expectation that it can be downloaded and installed via either CPAN.pm or CPANPLUS.pm. There are a few modules which have a complex installation process which are just too much for an auto-install to handle. Such modules shouls explicitly note this fact in the main POD and README. You can still have CPAN as an everything-about-perl repository, it just shouldn't be in the modules section.

[doom]

eserte:

... or even perl-related emacs lisp files to CPAN ...

Can you tell me where those are? I'd like to see an example of the right way to do it.

[tilly]

My opinion has always been that I like what the Module::Build folks are trying to do, but I hate their attitude. The example that I point to of that is their trying to push people away from using the simple compatibility layer because they want to guarantee that people hear of Module::Build. It seems to escape their attention that they are guaranteeing that people will first hear of Module::Build by being pissed off, and this isn't a very good thing.

That they would make other major social mistakes does not surprise me, although I have no idea how accurate the substance of your claims are about this one.

[autarch]

My opinion has always been that I like what the Module::Build folks are trying to do, but I hate their attitude. The example that I point to of that is their trying to push people away from using the simple compatibility layer because they want to guarantee that people hear of Module::Build. It seems to escape their attention that they are guaranteeing that people will first hear of Module::Build by being pissed off, and this isn't a very good thing.

I'm not sure where you get this from. The only time I see Ken discouraging people form using the compatibility layer is when there is something that cannot or will not be emulated by Module::Build. For example, Module::Build's compatibility layer doesn't emulate MakeMaker's PREFIX stuff. Ken decided not to do this because the way this is done in MakeMaker is insanely complex. M::B does offer a comparable feature (install_base=...), but it's much simpler.

I've never seen him tell people not to use the compatibility layer in their modules, and in fact I recall that he and I actively worked on it a long time ago, and he continues to work on it now.

[tilly]

See the discussion at Re: Re: Re: Acme::Lingua::Pirate::Perl author needs encouragement to add Makefile.PL.

Following that thread, I sent email to Ken Williams suggesting that the documentation for Module::Build::Compat not say that the preferred scenario is the one where you omit Makefile.PL and just tell people what to do in the README. Instead I thought that people should default to having passthrough present to install Module::Build for them. My point was that the resulting problems will mostly be felt by people who are trying to do something else (eg sysadmins doing a semi-automated install) who were only going to be annoyed at the extra difficulty. He replied saying that he didn't want to do that because he really wanted as many people as possible to learn about Module::Build. As I recall, the response got sent to some Module::Build mailing list, there was brief discussion, and the topic got dropped. I never followed up, and the documentation for Module::Build::Compat still says that the preferred scenario is to not provide compatibility with Makefile.PL, which will break people using CPAN to do installs.

You can make of this what you will. As you might have guessed from my previous post, the episode left me with a bad taste. Furthermore any module that I happen to notice following Ken's advice is broken in my books, and I'll not fail to describe it accordingly if the occasion arises.

Feel free to pass this message on to Ken if you wish. I presume that he is aware of my opinion, and likely doesn't care. At least he didn't care before, and I know of no reason for that to have changed.

[demerphq]

Im with tilly on this one. In principle Module::Build is a good idea. In follow through its been terrible. Breaking the CPAN build process was a _big_ mistake and IMO has essentially ensured that Module::Build will _never_ replace ExtUtils.

3. Why has Module::Build decided adding 'PPM-' to the beginning a good idea?
4. Why has Module::Build suddenly decided to affect CPAN without conferring with the module authors list, or the CPAN/PAUSE maintainers, or considering the bigger effects.


Personally I think the answers to these two questions are plain and simply Hubris. They think that its up to them to decide aspects of the future of perl without consultation with as much of the community as possible. Once they realize that there are tons of hackers out there who will ignore their work because of their attitude I'm hoping that they'll see the light and start playing ball. Splintering the community for the reasons they have is just plain bad for perl. Its sad.

[autarch]

4. Why has Module::Build suddenly decided to affect CPAN without conferring with the module authors list, or the CPAN/PAUSE maintainers, or considering the bigger effects.

Personally I think the answers to these two questions are plain and simply Hubris. They think that its up to them to decide aspects of the future of perl without consultation with as much of the community as possible.

Actually, the answer to #4 is really, really simple. Barbie is on crack. Module::Build has nothing to do with people uploading PPMs to CPAN. Module::Build has some code that attempts to build a PPM. If that code has problems, patches and/or bug reports should be sent. If people are uploading PPMs to CPAN and this is causing problems, then the person doing the uploading should be contacted and/or PAUSE/CPAN should be modified.

As for #3, I don't get that naming scheme myself, but I don't think anyone working on Module::Build did it as some sort of "Perl domination scheme", contrary to your rather fevered imagination. If there's a better (aka more standard and accepted) naming scheme, I'm sure Ken would like a patch, especially considering that he doesn't use PPMs himself.

The paranoia and anger in this whole thread is really wacko. Instead of assuming Ken & co. have some horrible plot, or are motivated by some sort of overwhelming ego, maybe you should consider that Module::Build is still being built, and that for the Win32/PPM side there has been very little input from Win32 people besides Randy Sims and a few others, and basically nothing out of ActiveState. I suspect that those problems Barbie found which are the fault of Module::Build are problems created simply by lack of resources and input.

Have any of the people doing the complaining in this thread actually chimed in on the Module::Build mailing list?

[demerphq]

Have any of the people doing the complaining in this thread actually chimed in on the Module::Build mailing list?

Yes. Bug reports and complaints were ignored. When the subject of releasing packages into CPAN _without_ a Makefile.PL came up the reaction was not pleasant. This decision singlehandedly has turned a large part of Perl community against Module::Build. Encouraging people to release unbuildable modules on CPAN was a _bad_ idea, especially as for quite some time no-one on PM on a Win32 box (the single largest group of users of Perl) could even get it installed.

The paranoia and anger in this whole thread is really wacko.

Thanks for your comments autarch. With an attitude like that its no wonder you dont get the issues being raised here. Maybe if folks like yourself took the concerns of folks like us a little more seriously Module::Build would be in wider use, and recieve wider encouragement. I know that from observing the CB there is almost nobody championing Module::Build here, and I think that is a reflection of the poor comunity relations (and decisions) made by the group responsible.

I wish I could be more positive about this actually. I had breakfast with Ken once and I know he is a nice guy. But M::B has definately managed to turn me completely off, and I say that as someone who thought Kens ideas when he presented them were good. (Although iiirc I made the point that breaking the existing Build process was a bad plan even then.)

[Corion]

I recently moved one of my modules over to Module::Build because I don't like make and all the things it entails, and ExtUtils::MakeMaker turned me off due to its complexity and uglyness for expansion.

The first thing that really annoyed me was, that there was no pass-through Makefile.PL included and that I had to hunt down one of your distributions to find a Makefile.PL so that the make && make test && make install dance still works. I don't like make, but it is a very convenient way to unify my automated nightly testing scripts. For something that claims to be the next best thing, this was a bad decision.

Recently, I've gone to writing some meta-packages that automate the installation of other modules, and while battling it out with ExtUtils::MakeMaker, I found it actually not that convoluted and ugly, as long as it is about generating one-shot makefiles and not some ingenious framework to do it all.

I think that the lack of Win32 feedback mostly stems from people shortly evaluating Module::Build under Win32 and then deciding that it's not worth the bother. If you want acceptance, you will have to actively seek out the people there, and not supporting a proper, automatic CPAN installation will not make people like Module::Build, at least, it made me not like it.

[barbie]

Barbie is on crack.

The paranoia and anger in this whole thread is really wacko.

Only in your post. If people happen to disagree with your point of view, resorting to personal attacks and vitriol only does a disservice to the discussion. At no point in my original post did I personally attack you, Ken or any of the other developers, so why do you feel the need to unleash your venom on me? For the record, despite my past, I don't do and have never done drugs.

Module::Build has nothing to do with people uploading PPMs to CPAN.

I think you need to carefully think that reasoning through. People use Module::Build to create distributions so they can distribute them to a wider audience. Part of that distribution process, in many cases, involves uploading to CPAN. Why should it be automatically assumed that someone who creates a ppm package, using M::B, will not follow the same route as they have for other distributions? While it might not directly upload to CPAN, it is part of the process that people use to upload their modules onto CPAN.

If people are uploading PPMs to CPAN and this is causing problems, then the person doing the uploading should be contacted and/or PAUSE/CPAN should be modified.

Why deal with the symptoms, which could cause a myriad of unforeseen problems, rather than look at the root of the problem? Blankly assuming you are right and everyone else is wrong, is not going to solve any issues there might be.

I don't think anyone working on Module::Build did use the naming scheme as some sort of "Perl domination scheme"

...assuming Ken & co. have some horrible plot.

I never said they did, or implied they did. I said that the discussion, both on the M::B list (it would appear) and to a wider audience, was not very well thought through, and the ideas perhaps too quickly implemented. I actually think the bigger aims of M::B are worth achieving, but the steps getting there are increasingly leading to frustration from the wider community. I also wanted to know whether my setup was an isolated case, or whether others has experienced similar problems. It would appear that they do. If I was to ask on the M::B list whether M::B was the latest and greatest, I wouldn't have expected a balanced view. I was hoping that those that have had problems were more likely to be residing here than on a module list, for which they have little or no interest in joining.

Have any of the people doing the complaining in this thread actually chimed in on the Module::Build mailing list?

Wildly claiming I am "on crack", have a "fevered imagination" and an "overwhelming ego" is nothing short of a personal attack. I am extremely doubtful Ken and the other developers share such vitriolic ideas towards me, and they are not deserving of this discussion. Inferring doubts over my mental stability and implying I'm a drug addict is both personally insulting and insulting to the community and M::B developers. Why should I join a mailing list to seek further discussion and hopefully a resolution, when I am now likely to be flamed with personal abuse, which has nothing to do with the problems of M::B and anyone's efforts to find a solution? I would suggest you take a long hard look at how you approach your responses in future and leave the personal insults alone.

If you want people to get involved with the development, there are better ways of achieving this than your efforts here in this thread.

[kwilliams]

I don't generally read PerlMonks (though I wish I had time to), but I heard about this particular thread so I checked it out. I have the following comments:

1) If Module::Build creates PPMs in some non-good way, please let us know on the Module::Build list so we can fix it. I'm not likely to find bugs in the process myself, since I don't use PPM.

2) The fact that Module::Build creates PPMs doesn't mean that people have to upload them to CPAN. That's a seperate issue. People have been uploading PPMs to CPAN before M::B existed, and they will continue to do so. Personally I don't see the need to put them on CPAN, but it's not for me or Module::Build to say.

3) I try to never "ignore" anyone's bug reports. If I seem to be ignoring something, send a message to the list in order to get back on our radar. There are a lot of concurrent issues in M::B and some of them are simmering on the back burner in deference to more pressing stuff.

4) My overarching project philosophy is that M::B is simply an alternative to MakeMaker, and if it doesn't look *better* than MakeMaker for your needs, then you don't have to use it. Many modules don't really need the extra power that M::B provides.

5) The issue of compatibility with CPAN.pm is something we're working on improving, and if I may say so myself, it's getting pretty good. I have no interest in subverting MakeMaker. I do have an interest in providing an alternative that's so much better that many people want to use it.

Note that you can send a message to the list even if you're not subscribed, I'll eventually approve your message.

Please remember that this is an open-source project, it doesn't descend in complete form from the heavens. Yeah, there are bound to be things that we didn't think through as thoroughly as you might wish, but on the whole I think the project has been very successful so far, and seems to have the capability to grow quite a bit more. And I have fun working on it, so I'm going to continue to do so.

-Ken

[jacques]

This is sliding toward insanity. The shark music from "Jaws" starts softly in the background ...

See my post Java is from Mars, Perl is from Venus

[barbie]

I disagree. Tying to keep some sort stability to the distributions, such as how their created and how their installed, as well as where to get them from and how to distiguish one type of install from another, is prefectly reasonable. By creating a mish-mash of everything, which is what is slowly happening at the moment, perhaps is sliding toward insanity.

However, I don't think it unreasonable to try and promote the idea that there are few different ways of installing Perl distributions. Underneath they are the same distribution, it's just that for some, they only know PPM, others use CPAN/CPANPLUS, etc... Afterall isn't Perl about having more than one way to do it? All I'm trying to suggest, is perhaps we ought to think about formalising some of the messages we are giving out to people on where to get Perl distributions and how to install them.

[jacques]

I think most intelligent people would agree that standards are a good thing. Your two paragraphs, with two opposing views -- "a mish-mash of everything" and "isn't Perl about having more than one way" -- reveal a mind torn between common sense and a philosophy taken to the extreme.

[randys]

I just wanted to drop in and make a few comments on the discussion. I hang out on the M::B list and occasionally try to help either when users post about problems or by suggesting patches, etc. (I'm the one responsible if there are any outstanding Win32 problems as most of that code is my "fault".)

I'm not sure I understand the negative perceptions wrt Ken and the development of M::B. The M::B list is open to everyone; I usually make it point to mention it anytime I get a chance. All thoughts/ideas/suggestions are welcome. There have been a few times where it might have seemed that discussions where cut short, but this (afair) was primarily because the discussion was a repeat of previous discussions.

On the issue of MakeMaker compatibility, I believe it was decided a long time ago that after years of tacked on features, MakeMaker had become a kludge. Micheal (the current maintainer) whole heartedly agrees and has actively encourage M::B to separate from MakeMaker where it makes sense and provides for a better design/implementation. I agree with their design goals in this regard; it makes sense. In fact, I probably have more radical views on this as I believe that if you can't maintain complete compatability then you should be as different as possible. There is no way that M::B can be better without being different.

As for the PPM thing. As Dave said, M::B providing the ability to generate a ppm has nothing to do with them being uploaded to CPAN. They definately don't belong there imho. I wish there wasn't a need for PPM, but unfortunately there seems to be. It would be nice to see it go away now that Microsoft has release free commandline version of their compiler, but I don't see ActiveState stopping it as it is seen as an easer install system by most of their users.

As for the name of the ppm, it was arbitrarily chosen to give it a name unique from a regular CPAN distribution. Now that it has been sugested I much prefer a name like module-name-version.ppm.tar.gz. Hopefully that change will make it into the next version.

As for any other criticism of M::B please post them to the M::B list. M::B needs more feedback from the communtity if it is to improve. At last count there were over 200 unique distributions on CPAN, so it is growing. It's up to the community to decide the direction. You will not be flamed for posting criticisms on the list.

Regards,
Randy W. Sims

[eyepopslikeamosquito]

I personally would like to see a repository of RPMs of Perl distributions available

In case you haven't seen it already, rpmpan.

[adrianh]

Random comments in no particular order...

---

On the PPM front all Module::Build did was provide a way of automating the creation of a PPM distribution. Something that ExtUtils::MakeMaker and other tools already support to different extents.

The only additional things that M::B's ./Build ppmdist does over EU::MM's make ppd is automate the creation of the package archive, and add it to the codebase tag of the PPD file.

I agree with the other people who have already mentioned that the basic problem is with people uploading package archives to CPAN. This isn't M::B's fault. M::B doesn't support uploading PPM distributions to CPAN, or advocate it in any way. Neither does EU::MM. Indeed I don't know of anybody advocating the upload of package archives to CPAN.

I agree that using a PPM- prefix to differentiate a PPM package archive from a normal distribution was a mistake since it can be easily be confused with a normal module distribution with a PPM prefix. As soon as this was pointed out to Ken he said he's willing to make a patch. This, in my experience, is Ken's usual reaction to bug reports.

---

I think standard platform-specific package archive mirrors would be a nice idea. They would save a lot of time for those of us unfortunate enough to have to deal with platforms that don't come with build tools by default.

However IMHO they don't currently belong on CPAN, which has no infrastructure to support them in a useful way.

---

EU::MM is not going away. None of the M::B developers think EU::MM is going away. To the best of my knowledge nobody has said that EU::MM will be removed from core perl. M::B is an alternative (and a good one in my opinion), but if you don't want to package your modules with it then don't use it. EU::MM will be around for as long as Perl is around.

---

In my opinion the M::B folk are not pushing people away from using the Module::Build::Compat layer.

The three different Module::Build::Compat scenarios are, I believe, described fairly in the Module::Build::Compat documentation.

In the documentation Ken expresses his personal preference for the no Makefile.PL option. Ken's preference is not my preference. Taking a look at the M::B distributions on CPAN the vast majority of people who create packages with M::B also have a different preference from Ken. I still fail to see the harm in Ken expressing his personal preference. "I prefer" is a very different statement from "The preferred". The downside in choosing this option is clearly described.

(In fact Ken has now said he'll be removing the text expressing his preference.)

I also believe the default value of create_makefile_pl is correct. CPANPLUS already supports calling ./Build instead of make. I imagine that CPAN will be patched to do the same by the time that 5.10 arrives. In the medium-to-long term the compatability layer won't be needed for CPAN(PLUS) installs. In the short term people making distributions can easily generate appropriate Makefile.PL files automatically.

Looking at all the modules on CPAN now using M::B generated Makefile.PL files I think the rumours of M::B breaking CPAN are greatly exaggerated.

---

Some people have apparently had bad experiences with M::B distributions. To supply an additional data point I have not.

I've started looking at M::B seriously a bit under a year ago as various EU::MM installs were causing me severe maintenance and cross-platform problems. I now use it for all of my personal in-house projects, for all of my client work and for one of my CPAN modules (and I'll probably add it to the others when the Spare Time Fairy next visits.)

I've found it far easier to develop with then EU::MM, and have yet to receive a single complaint about any of my M::B distributions on any platform (including Windows). I wish I could say the same about some EU::MM based distributions.

Other Perl developers I know have had similar experiences.

There are certainly areas where M::B can be improved. However in my opinion it is ready for real world usage now and I would have no hesitation in recommending it to others.

I doubt that there would be as many M::B based distributions on CPAN if it did nothing but bring in a stream of bug reports, abuse and broken CPAN builds.

---

Some people have apparently had bad experiences with M::B developers. To supply an additional data point I have not.

I'm certainly not "widely known in the community". Only three CPAN modules to my name and I've never been to a Perl conference or a Perl Mongers meeting in my life. I'm Just Another Perl Hacker :-)

Despite this poor standing my comments and questions have always been answered quickly, accurately and politely by Ken and others.

I have not encountered any excessive hubris on the part of the developers, and they have always seemed positively eager to accept patches from others and get M::B working on as many platforms as possible. I've never seen bug reports being ignored.

There's an archive of the M::B e-mail list available on gmane for those cannot stomach the ghastly sourceforge mail archives. I would encourage people to take a look at them and judge for themselves.

I would actively encourage users who are encountering problems with M::B distributions to mail the list so the bugs can be fixed.