[tor-project] reminder meeting (Re: Follow up Gitlab next steps (Re: update on ticket system discussion)

[Gaba]

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=%E2%9C%93&state=opened&label_name[]=None
> 
> 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
> 

-- 
Project Manager: Network, Anti-Censorship and Metrics teams
gaba at torproject.org
she/her are my pronouns
GPG Fingerprint EE3F DF5C AD91 643C 21BE  8370 180D B06C 59CA BD19