[Tracker-discuss] Working with the sourceforge screenscraper

Erik Forsberg forsberg at efod.se
Mon Nov 13 07:27:03 CET 2006

Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

> And, I don't think it is that useful to always use a tracker filled with
> real data while working on the schema / templates / et al., since I'd expect
> us re-initializing the tracker rather often. Having only a handful of
> (dummy) issues makes more sense.

On the other hand, using real data as often as possible makes sure we
find as many importer bugs as possible, and also forces us to keep the
importer up to date with any changes (layout-wise etc.) at sourceforge
so that we don't find out in the very last moment that we can't import

> Only once we are converging towards the final tracker should we start
> importing the real data. Thus, having a single run of the transfer script
> should be enough.

Just for your knowledge, "a single run of the transfer script" takes
many hours and is, due to the instability of sourceforge, a very
error-prone project. Not to mention that sourceforge block me for half
an hour once in a while for fetching too much data. 

Also, let's make it clear that this is a process in two steps:

1) Fetch all data from sourceforge into a set of XML files locally.
2) Import into roundup.

I would be much more comfortable if we had a process where step 1) is
always kept in sync with sourceforge. This would keep us much less
dependent on sourceforge being up and working at the time for the
final conversion.

- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>


More information about the Tracker-discuss mailing list