view release on metacpan or  search on metacpan

Todo  view on Meta::CPAN

	* remove the 0.00 from the verbose overview in the Merged column in the
	Z row. DONE

	* write tests that expose the problems of the last few days: cascading
	client/server roles, tight coupling for secondary RFs, deletes after
	copies.

	* Some day we might want to have policy options for the slave:
	tight/loose/no coupling with upstream for secondary RFs. tight is what
	we have now. loose would wait until a gap occurs that can be closed.

2008-10-14  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* revisit all $rfs->[$i+1] places if they now make sense still

2008-10-11  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* another bug is the fact that the mirror command deletes files before
	it unhides the index file, thus confusing downstream slaves. We must not
	delete before unhiding and must delete after unhiding. FIXED.

	* new complication about the slave that is playing a server role.
	Currently we mirror from newest to oldest with a hidden temporary file
	as index. And when one file is finished, we unhide the index file.
	Imagine the cascading server/slave is dead for a day. It then starts
	mirroring again with the freshest thing and unhides the freshest index
	file when it has worked through it. In that moment it exposes a time
	hole. Because it now works on the second recentfile which is still
	hidden.

	We currently do nothing special to converge after such a drop out. At
	least not intentionally and robustly and thought through.

	The algorithm we use to seed the next file needs quite a lot of more
	robustness than it currently has. Something to do with looking at the
	merged element of the next rf and when it has dropped off, we seed
	immediately. And if it ramains dropped off, we seed again, of course.

	Nope, looking from smaller to larger RFS we look at the merged element
	of this RF and at the minmax/max element of the next RF. If that
	$rf[next]->{minmax}{max} >= $rf[this]->{merged}{epoch}, then we can stop
	seeding it.

	And we need a public accessor seed and unseed or seeded. But not the mix
	of public and private stuff that then is used behind the back.

	And then the secondary* stuff must go.

	And we must understand what the impact is on the DONE system. Can it go
	unnoticed that there was a hole? And could the DONE system have decided
	the hole is covered? This should be testable with three directories where
	the middle stops working for a while. Done->merge is suspicious, we must
	stop it from merging non-conflatable neighbors due to broken continuity.

	FIXED

2008-10-10  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Slaven suggests to have the current epoch or the whole current
	recentfile available from the HTTP server and take it away with
	keepalive. This direction goes the granularity down to subseconds.

	We might want to rewrite everything to factor out transport and allow
	the whole thing to run via HTTP.

2008-10-09  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* smoker on k81 fetching from k75 to verify cascading works. See
	2008-07-17 in upgradexxx and rsync-over-recentfile-3.pl.

	* maybe the loop should wait for CHECKSUMS file after every upload. And
	CPAN.pm needs to deal with timestamps in the future.

	* do not forget the dirtymark!

	Text: have a new flag on recentfiles with the meaning: if this
	changes, you're required to run a full rsync over all the files. The
	reason why we set it would probably be: some foul happened. we injected
	files in arbitrary places or didn't inject them although they changed.
	The content of the flag? Timestamp? The relation between the
	recentfiles would have to be inheritance from the principal, because any
	out of band changes would soon later propagate to the next recentfile.

	By upping the flag often one can easily ruin the slaves.

	last out of band change? dirtymark?

	Anyway, this implies that we read a potentially existing recentfile
	before we write one.

	And it implies that we have an eventloop that keeps us busy in 2-3
	cycles, one for current stuff (tight loop) and one for the recentfiles
	(cascade when principal has changed), one for the old stuff after a
	dirtymark change.

	And it implies that the out-of-band change in any of the recentfiles
	must have a lock on the principal file and there is the place to set the
	dirtymark.

	* start a FAQ, especially quick start guide questions. Also to aid those
	problematic areas where we have no good solution, like the "links"
	option to rsync.

	* wish feedback when we are slow.

	* reduce mccabe

	* Remove a few DEBUG statements.

	* The multiple-rrr way of doing things needs a new option to rmirror,
	like piecemeal or so. Not urgent because after the first pass through,
	things run smoothely. It's only ugly during the first pass.

	* I have the suspicion that the code is broken that decides if the
	neighboring RF needs to be seeded. I fear when too much time has gone
	between two calls (in our case more than one hour), it would not seed
	the neighbor. Of course this will never be noticed, so we need a good
	test for it.

	* local/localroot confusion: I currently pass both options but one must
	do.