You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

In order to divide the effort of developing generic upgrade tooling for migrations from fedora 3 to fedora 4, it may be useful to bisect the problem into concerns about "data migration" and "functionality migration".  There are clearly some overlap as well as inter-dependencies between these two broad categories of migration concerns, but nonetheless it may serve as a useful way to break down the problem for early work.

Data Migration

For preservation repositories (and to a lesser extent, access repositories) migration of data or content in a way that is lossless, transparent is necessary.  Because fedora 3 has maintained a relatively simple, stable and complete serialization of objects (foxml), any tool or strategy with the primary concern of retaining all fedora 3 object data might be best served working from that serialization format. 

Data migration discussion...

Functionality Migration

Besides the data, fedora 3 (and 2) exposed functionality on objects through its dissemination framework, access control framework, embedded triplestore, coupled indexing framework and other mechanisms.  Especially for access repositories, developing a path where this functionality can be retained is essential.

Current Work

 

key summary type created updated due assignee reporter priority status resolution

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  • No labels