Hi!
El 9/17/19 a las 1:13 AM, teor escribió:
Hi,
I won't be at the meeting. I've read the migration proposal and the network team feedback pad.
Sorry that the time is not right for you.
Here is my extra feedback/notes:
Migrate / Test / Rollback
- What is the plan for testing the migration?
- What data must be successfully transferred?
- What is the rollback plan, if the migration fails?
We need a concrete plan for this. In the meeting today we taked about drafting this.
Data migration
- how does Parent ID get transferred?
- note: will will lose the ability to have multi-level parent/child relationships
Proposal: parent-NNNNN tag, placed on child tickets *and* parent ticket
We still didn't talk about this. I created an issue in ahf's migration repo to look at this https://dip.torproject.org/ahf/trac-migration/issues/1
New processes
- When we replace fields with tags, how do we ensure consistent milestone, version, etc. spelling?
Which one would be the problem? Labels can not be created by anybody. People can apply labels that already exist.
We might want to use Kanban boards / lanes (or GitLab tasks) rather than:
- ticket queries embedded in wiki pages
Not sure how we are going to do this. It may depend on the wiki page and what is its purpose. Some of them may be converted into a board. Some of them may still exist and link to a query.
- CI tags
Labels can be used for this.
- sponsors?
Labels
- releases?
Milestones
- parent / child tickets?
Ticket ID process changes In Trac, people can use a ticket ID to find a ticket. In GitLab, each project can create *new* tickets with the same ID as tickets in other projects. (Even if we block all Trac ticket numbers, new tickets won't be blocked.) What processes will we need to change, now that ticket IDs need a project?
- ChangeLog / ReleaseNotes: ok, project can be determined from context
- ticket bot: needs project prefix
- can implement search order for non-prefixed numbers: legacy, tor, …
- any other contexts?
This was part of the conversation today (look at the notes). Mostly we will have to reference to to a specific project for a ticket. project#NNN instead of #NNN
Migration - existing projects If a project is already set up in GitLab, what do we do with Trac / GitLab ticket number conflicts?
Projects will get removed and recreated with the import. Trac is still the source of all truth for tickets. We will check for projects that may have been udpating gitlab and not trac.
The idea now is to keep numbers from trac and start new issues in gitlab after a specific number.
Proposal: each project consists of (GitLab tickets before migration)(blocked ticket numbers)(migrated tickets)(new tickets) Proposal: we create a new project for each transferred project, block the Trac ticket numbers out, transfer the legacy tickets, transfer the test project ticket, start opening new tickets
Yes. Something like this. Please look at the notes.
Keyword search Copied from the network team pad: When a field migrates to a keyword, is there a good way to search for tickets lacking any keyword corresponding to that field? gaba: yes. you can filter by issues that do not have a labels (so for example if sponsors are keywords, how do we search for issues with no sponsor keyword? Do we have to list every sponsor keyword?) gaba: there is a value 'None' https://dip.torproject.org/torproject/core/tor/-/boards?scope=all&utf8=%...
New questions: But what if the ticket has *some other* keywords, but no sponsor keyword? We'd need a regex like trac's !~=sponsor It looks like -sponsor or -sponsor* should do what we want, but we should check: https://docs.gitlab.com/ee/user/search/advanced_search_syntax.html
Yes
Suggested data migration / test details
Blockers
- If these fields aren't transferred as specified, we must roll back.
Ticket number Summary Description Comments (commenter, comment text) Milestone Keywords Actual Points Points Sponsor Component Reviewer
Important
- If these fields aren't transferred as specified, they should be fixed as soon as possible.
Type Version Reporter Parent ID - how does Parent ID get transferred?
Optional
- It doesn't matter if these fields are transferred or not.
- We probably can't transfer these fields in a useful way
Cc Priority Severity Trac magic links to ticket IDs and wiki pages
We are planning to migrate all info from tickets.
T