4 ms·

I think the gitlab export format is actually not too bad: Just a tar file with the git repo in bundle format and all the gitlab specific components in ndjson fo

I think the gitlab export format is actually not too bad: Just a tar file with the git repo in bundle format and all the gitlab specific components in ndjson format (and data in those ndjson files looks fairly straightforward as well on first glance). The problem is though that there are no real interoperable formats for things like tickets, project boards, CI setup, etc. (that I am aware of anyway). So everyone invents their own export format (if they even bother to implement that functionality in the first place) and importing into a different platform will always require writing some extra code and mangling of the data to account for different features.

em-bee 4y ago
issues could be exported as email threads. not only would that make them immediately readable offline by any mail client, but it would be easy to share them, and writing an import handler would also not be hard.
- welterde 4y ago
  Writing an import handler for the json files is not more difficult than writing an import handler for email threads. And you want the import to reproduce what you just exported and since the source was not an actual email thread you'll have to stick quite a lot of additional information into many X-.. fields in the email headers to be able to reconstruct the original issues on import. If you want it to be in email format it would make more sense to just write a small tool that just converts the json files into email threads after the export as an additional processing step.
  - em-bee 4y ago
    not an actual email thread github and gitlab at least send out all issues by email, so that conversion is mostly done. they can also receive email replies, so import is at least partially done too. (i don't know if new issues can be created by email). and i believe it will be easier to standardize mail header fields than a json format. json could then be reserved for raw data exports that are as close as possible to the native data structure of a system, while the email format would be the compromise that everyone can agree on.

em-bee 4y ago

issues could be exported as email threads. not only would that make them immediately readable offline by any mail client, but it would be easy to share them, and writing an import handler would also not be hard.

welterde 4y ago
Writing an import handler for the json files is not more difficult than writing an import handler for email threads. And you want the import to reproduce what you just exported and since the source was not an actual email thread you'll have to stick quite a lot of additional information into many X-.. fields in the email headers to be able to reconstruct the original issues on import. If you want it to be in email format it would make more sense to just write a small tool that just converts the json files into email threads after the export as an additional processing step.
- em-bee 4y ago
  not an actual email thread github and gitlab at least send out all issues by email, so that conversion is mostly done. they can also receive email replies, so import is at least partially done too. (i don't know if new issues can be created by email). and i believe it will be easier to standardize mail header fields than a json format. json could then be reserved for raw data exports that are as close as possible to the native data structure of a system, while the email format would be the compromise that everyone can agree on.