view release on metacpan or  search on metacpan

Todo  view on Meta::CPAN

	between 2006-01-26 and 2006-02-01 (and I wrote a paragraph into the
	manpage how multiple ~/.cpan* directories could work)

2006-10-27  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Test if "reuse" works without metadata (timing issues because the
	entries do not exist yet?) No, it doesn't! FIXED in rev 1149

	* Investigate what happens if a user has CPAN 1.8802 and Module::Build
	0.2611 and tries to upgrade to 0.2805. Gabor says, it fails. If it
	fails, I'll have to coin a new phrase for the bug: install suicide? No
	need to worry, ATM it works more or less well, but it doesn't fail
	rightaway. CHECKED after rev. 1149 or so.

	* Rethink if Ilya's expire_old_builds is better the build_dir_reuse in
	that it sets an expiration date. His -1 is my 1. His 0 is my 0. I have
	nothing like his 30. The name of his variable is not good in that one
	could believe that setting expire_old_builds==0 might mean to do NOT
	expire them at all. Hmm. I think my build_dir_reuse is good enough.

	* Todo: invent a test for build_dir_reuse. It should construct a YAML
	file before test start that will then be picked up and lead to some
	"already in..." which we test for. And then we use force to actually get
	that distro. Or we do that for an inexistent distro so that we do not
	have to rewrite the test after each new release? DONE in rev. 1152

2006-10-25  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: if the user does not want to install a module (say a
	build_requires), give him options to use the already tested module even
	after he has left the shell.

	Ilya seems to say, people do NOT want to install a number of modules
	because they are not yet sure if they really need them. But they have
	tested them and have them still lying around in their ~/.cpan/build
	directory. So we should give them a chance to use them next time they
	come around with the same perl.

	DONE in rev. 1140 with build_dir_reuse

	* Todo: put the distro ID close to the OK or NOT OK line DONE in rev.
	1136 or so.

	* What was the deal with

Package 'CPAN' already declared with version '1.88_57'
ignoring new version ''.
Looks good

	again?

	http://www.mail-archive.com/module-build@perl.org/msg00340.html

	* Since DBI is fixed I see other interesting breakages: Class::DBI,
	RPC::PlServer, GD.

	GD fails with 5.8.8 and 5.8.3

	Class::DBI fails with 5.8.8

	RPC::PlServer fails with 5.8.8 and 5.8.3 but only if Crypt::DES is
	installed

	OK, so nothing new.

2006-10-24  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Coro 2.0 works with bleadperl Yay! YAML for Coro with default answers
	written.

	* bug with notest pragma: it seems to remain in the distro object. I did
	a report DAGOLDEN/CPAN-Reporter-0.28_51.tar.gz, then I did a "notest
	install" on it. Then I reloaded and tried a "report" on it again and
	CPAN refused to run the test because of the notest pragma.

	FIXED in rev. 1132 but what is a good test for it? test WRITTEN in 1133.

2006-10-23  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* The ->VERSION bug was back for a short while. It happens when
	version.pm is not installed and Module::Build loads its own version.pm
	from <data>. There it finds 0.661 and this does something that isn't
	fool proof, very hard to diagnose and to reproduce. Easy workaround: do
	not check for Module::Signature->VERSION anymore. The test was on 0.26
	and we now have 0.55, so I guess, I can remove the version test.

	As soon as I have means to not call into Module::Build, this bug will
	diappear for sure, so no need to hunt it down from here. FINISHED in
	rev. 1123

	So recall: one can turn off sig_check, then install version, then leave
	and enter CPAN.pm and the bug should disappear. Or we release 1.88_57
	now. Update: I released 1.88_57 immediately after that.

	* SMPETERS fixed DBI-1.52. Thank you! YAML for DBI with patch address
	written

2006-10-23  Andreas J Koenig  <akoenig@iconmobile.com>

	* make a list of cpanconfig variables that can be changed via
	distroprefs. Extend the list and document it, so that people can look it
	up and do not have to read the source and can file bug reports against
	it.

	I fear for example that the preferred builder is not configurable(?)
	latter half FIXED in rev. 1124

	First half done with rev. 1125

	* Write an executive summary of the state of affairs wrt. distroprefs so
	we can decide about future directions. Update the README file to better
	outline the executive summary. Update the examples to better reflect our
	powers and weaknesses.

	What we have:

	- Give the user a simple system to store per-distro preferences related
	to environment variables, commandline args and stdin for the four
	commands of our traditional mantra: perl Makefile.PL, make, make test,
	make install (and symmetrically for M:B modules)