[Tracker-discuss] Working with the sourceforge screenscraper

[Stefan Seefeld]

Erik Forsberg wrote:

> 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
> data. 

Speaking of 'real data': Could you separate the translation of
issues from the translation of other data such as the possible
values (enumerators) for 'group', 'category', 'status', 'priority', etc. ?

The latter don't seem to change as frequently as the issues themselves (if
at all), and thus could already be coded into the new tracker (possibly
by means of initial_data.py). They are in a sense more part of the schema
than they are part of the actual tracker content. Also: any detectors
we will write will depend on them, so it's important to have them available
independently from the issues.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...