Please note that we care about freedom for both software and data here at Gna!.

We have setup at the early stages (in 2004) far more way to export or import data via realistic means (like rsync, svn dumps and such) than any other forge. It is maybe not true any more.

We have also arranged at many occasions specific tasks to import or export various datasets such as VCS repositories.

So we have arranged to have no legal bindings and the least technical barriers to let data move in and out of Gna!. The infrastructure itself has lived on different servers and with the help of different companies. The last move was precisely a consequence of a dubious legal constraint that arose.

Obviously we would be more than happy to provide and accept better interchange tools, since that would mean a more effective freedom. Right now moving your data is partly dependent on the adminsys availability and time which is quite scarce. And in some parts intimate knowledge of Savane (like XML dumps of tracker data). Most VCS repositories, files and such are simply rsync'able.

But I insist that platform 'owners' and their responsibility is key. Loic and I are left as the original founders (Mathieu, which was the real task force back in 2004, moved with another life plan), and we've showed 5 years of commitment to these goals. Loic has notoriously and more generally done so for er... 20 years.

If you are determined to be insulted there is nothing I can do to stop you. But that was not my intention; I am merely pointing out facts.

It is objectively true that large parts of a Savane project's state are effectively not accessible to be snapshotted and backed up. You may argue with the phrase "data jail", and you may sincerely intend for things to be otherwise, but it is nevertheless descriptive of the actual situation. I regret that the term offends you, but you would serve your users better by thinking of ways to fix the problem than you do by taking offense at the messenger.

You request patches rather than "mere reports". This seems to me more like an avoidance tactic rather than a constructive response, but I am in fact willing to back up my criticisms with code. Many of them could be addressed by an email bot or XML-RPC server doing queries to the back-end database, and this might be a relatively small, self-contained subproject. I could at least evaluate the possibility.

What implementation languages does the Savane project prefer or allow? Is Python one of them?

FYI, I filed the bug with MailMan and was immediately informed that this issue has been directly addressed in MailMan 3.

Accordingly, I suggest the Savane project should ensure that its codebase is MM3-compatible and then encourage Savane-using sites to upgrade.