Migration from Goobi.Production to Kitodo.Production

[stweil]

This issue was opened to collect requirements, coordinate activities and discuss different options needed for the migration from Goobi.Production to Kitodo.Production.

Some selected questions (numbered for later reference):

1. Rename directory Goobi/ to Kitodo?
2. Rename goobi subdirectories below Goobi? Which ones?

[matthias-ronge]

Renaming the packages could go together with generally reorganizing them, giving up the duplicate branches de.sub. and org.. Here is an approach how package structure could better represent the contents of the app:

Missing packages here mean to incorporate their contents in the best matching other packages. I would encourage to import the relevant UGH classes as well.

[henning-gerhardt]

Regarding general renaming from Goobi to Kitodo: In a short time period only visible Goobi names appearance should be replaced. No internal and only for a developer visible name should rename. In a long time period internal and for developer visible names should be replaced as it could break a lot of stuff.

Regarding package name renaming and in my humble opinion as developer: in a short time period there should no changes to current packages names as it breaks every existing third party plugin / module. In a med time period there should be an official interface declaration (API / ABI / SDK?) which should be used and changed only in major revisions.

Integration of UGH classes: should be discussed in general module concept discussion. Now UGH classes are in modular and separated from other source code and can be reused in other JAVA based projects.

[stweil]

@henning-gerhardt, what about making https://github.com/kitodo/kitodo-production the primary source (and https://github.com/goobi/goobi-production the fork)? The same change is needed for https://github.com/goobi/goobi-presentation, too.

[henning-gerhardt]

@stweil : I will forward your suggestion to @sebastian-meyer.

[sebastian-meyer]

Since the Goobi GitHub account will most likely be transfered to Intranda in the future, I don't think we need to worry about which repository to be the fork. Sooner or later the Goobi repository won't exist anymore and therefore the Kitodo repository will become the main repository anyway.

Aside from that, I think the Kitodo repository should be the fork, because essentially this is what it is: the Goobi repository is older and the Kitodo repository is forked from it - not the other way round.

[stweil]

From the GitHub point of view, a fork is a repository which usually does not get pull requests and issues. A fork is typically often synchronized with its base repository. Both is wrong for Kitodo.

[stweil]

Should new pull requests and issues be made on https://github.com/kitodo/kitodo-production?

What about existing pull requests? Can you transfer them to Kitodo?

[henning-gerhardt]

All old and used repositories are now moved to Kitodo organisation. Through this move all open pull requests and issues are transferred too. Active developers should update their git remote url to the new location. Old remote url should work for a while.

[stweil]

https://github.com/kitodo still needs to be configured to show people.

[sebastian-meyer]

You can't make all collaborators public by default. Everyone has to set himself visible.

[stweil]

Who is "all collaborators"? Technically I'm currently not one, as I cannot set myself visible. Maybe @matthias-ronge has the same problem.

[sebastian-meyer]

Since a few months GitHub distinguishes between "team members" and "outside collaborators". Team members are those people, who manage the repositories, while outside collaborators are all other contributors.
Outside collaborators are never shown under "people", while team members have to set themselves visible.

[henning-gerhardt]

Development on master branch already contain some renaming and more is comming, for 2.x this should not be done.