[Tails-project] Call for feedback: proof-of-concept of our i…

Delete this message

Reply to this message
Autor: intrigeri
Data:  
A: Public mailing list about the Tails project
Assumpte: [Tails-project] Call for feedback: proof-of-concept of our issues in GitLab
Hi,

please provide early feedback about the first proof-of-concept import
of our public Redmine data into GitLab:

https://0xacab.org/intrigeri/redmine-import-1/issues

This early PoC is clearly insufficient to evaluate every aspect of the
migration, but we hope that showing this to you now will help improve
the final migration. If you'd like to test modifying stuff, create
yourself an account on 0xacab and request access to this project.
Note that I've disabled email notification to avoid spamming
innocent bystanders.

I intend to organize the information gathered during this round in
10-15 days. Then I'll convey it to Enrico & hefee, who write the
migration code that makes all this possible.

This is not a hard deadline: I'm happy to gather feedback continuously
along the course of this project. But the earlier you take a look,
the greater the chances that we can incorporate your feedback.

There will be other calls for feedback as we make progress.


Known problems that we plan to solve later
==========================================

- Only public content: we haven't designed the authorization model yet,
and we have not decided where we can store our private content yet.
- All issues are in one single GitLab project, while our authorization
constraints will probably require that the issues for some teams live
in a different GitLab project.
- Links to Redmine point to our current Redmine, while after the final
migration, they will instead point to the upcoming static archive
of Redmine.
- Links to commits are not rendered; instead we see something like
"commit:tails|5703cbdf3c05ab2e53b8494b9a03260af34f3695"
- Issues have no assignee.
- The list of Participants (aka. "Watchers") is empty.
- Labels are grouped only by color, e.g. all priorities are blue.
The current proposal is to prefix labels like this: "P: $priority",
"C: $category", or "Priority: $priority", "Category: $category", etc.;
that's a common pattern on GitHub/GitLab.
- Internal links to an issue note (#124#note-6) are not rendered as links.
- Things that were deleted in Redmine but are referenced somewhere
appear as numeric labels.
- Labels with spaces in their name are not referenced correctly in the
"Metadata changes" section.
- Transitions of labels are not rendered nicely (no strike-through at the
deleted label).
- We did not design a replacement workflow for Core team
self-management (ala #16209) yet.
- I'm not sure if rendering existing "Blocked by" relationships
as a checklist is desirable. The good thing is that it enforces
this relationship. The bad thing is that it displays information
that's arguably wrong and at least confusing (X/Y tasks completed).
- Some of the "Original created by @xyz" information is incorrect.

Known problems that are side-effects of how we did _this_ import
================================================================

The final migration will not have these problems:

- We imported a snapshot of Redmine data from ~2 weeks ago.
More recent changes are missing.
- Each note has a footer like this: "By hefee on 2019-11-22T04:27:16
(imported from GitLab project)".
- Some links to tickets (#NNNN) are not rendered as links.

Known problems that we *might* be able to solve later
=====================================================

- All issues appear to have been created by the user account that did
the migration. We could fix that if we're migrating to a GitLab
instance on which we have admin credentials so we can impersonate
other users. Else, this problem will remain and the best we will
have is the free-form annotation in the issue description, e.g.
"Original created by @intrigeri on 17117 (Redmine)".

Known problems that have not been triaged yet
=============================================

See https://salsa.debian.org/tails-team/gitlab-migration/issues.

Known limitations that come with GitLab
=======================================

- There's no way to view an non-image attachment without downloading it first.
- The web UI may suggest to "upgrade" to a non-Free Software version of GitLab.

Cheers,
--
intrigeri