Re: [tor-project] gitlab next steps

A reminder that this meeting is tomorrow (October 1st) at 17UTC.

Tentative agenda here: https://pad.riseup.net/p/e-q1GP43W4gsY_tYUNxf

El 9/17/19 a las 12:47 PM, Gaba escribió:

Hi!

We met today to talk about the migration from trac into gitlab. The agenda and notes are in the pad (https://pad.riseup.net/p/e-q1GP43W4gsY_tYUNxf) and in the body of this mail.

You can look at the logs for the meeting in: http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-09-17-18.01.html

Next meeting will be on October 1st.

CONTENT OF THE PAD:

References: mail with context: https://lists.torproject.org/pipermail/tor-project/2019-July/002407.html planning document: https://nc.riseup.net/s/SnQy3yMJewRBwA7 migration code: https://dip.torproject.org/ahf/trac-migration ticket: https://trac.torproject.org/projects/tor/ticket/30857

Agenda September 17th

• Revisit agenda
• Update that where we are at
• Stuff that seems that still needs to be resolved or decided upon:
  • IRC ticket number bot
  • redirection from bugs.torproject.org to gitlab ticket (legacy

project resolve links?) * structure for projects * anonymous users/ user registration * Preserving existing trac data

 * data migration process

• Next steps

Notes

Logs: http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-09-17-18.01.html

On ticket numbers:

1. IRC bot for tickets (zwiebelbot) - get ticket's title and a link to

the ticket when we write #TICKET-NUMBER. In gitlab tickets are per project.

possible solutions:

1.  write a plug-in for the bot that is running zwiebelbot to fetch

the data via gitlab's api. we will lose the short hand ticket id syntax (#xxx) and have to use project-name#xxx instead with that

2. redirect from bugs.torproject.org/#TICKET-NUMBER to the right issue

in gitlab

possible solutions:

1. a part of the migration from tickets from trac to all the

different gitlab project, we save a mapping between the old ticket ID's and their new project paths, which would allow us to update the redirection service with a tool that looks at htis mapping and does the redirect

2. all tickets first get migrated to a single project where there's

a one to one mapping between ticket IDs in trac and gitlab so bugs.tpo/N point to dip.tpo/legacy/N

for future issues (not legacy) we will have

bugs.torproject.org/project/NNN

3. the question is how to keep ticket numbers consistent across the

migration if we want to have tickets split between mut roject

Nick's Absolute Requirements: 1. If there is #NN in trac, and there is tor#NN in gitlab, then they must be the same bug. 2. If there is tor#MM in gitlab, and it is the same as some bug #NN in trac, then MM must equal NN.

NEXT STEP: AHF will experiment with aproach 2.2 on moving tickets from legacy project into its own. (ahf will move forward)

Structure for projects:

Proposed structure:



Group TEAM X  - all team members have ownership on this group.

        Project X1 - the ones related to repositories. Example:

snowflake or little-t tor.

        Group XX1 - example pluggable transports for anti-censorship

team

Project Y - at organization level, example scalability that may

touch all teams.

NEXT STEP: rename the group 'torproject' to tpo (gaba will do it) NEXT STEP: add the rule "do not have two elements in the project naming tree with the same name, even if they are not ambiguous" NEXT STEP: add the rule "short names when possible for projects or groups"

Anonymous users/ user registration:

Options: (1) cypherpunks - people not ok with this one as there are trolls (2) salsa custom signup form - some people say this is not totally effective (3) akismet + recaptcha - not really an option because it blocks tor users and tracks people (4) write a custom captcha plugin - some people say this is not totally effective (5) open registration - spam is a huge issue here

Proposals:

1) i suggest we manually register gitlab accounts for known good

contributors and open up contributions from github issues (from catalyst)

2) open registration with some spam-limiter, and moderate accounts

(from nick)

3) consider experimenting with the salsa custom signup form

NEXT STEP: We need more research on how to deal with spam in gitlab. NOTHING DECIDED YET. (gaba will check)

Preserving existing trac data:

NEXT STEP with a list of things that you will not see in gitlab from trac

Data migration process:

NEXT STEP: write down a more concrete plan for migration. What do we test for? When we do it? Who is helping? - (gaba will do it)

Issues about migration will be deal here: https://dip.torproject.org/ahf/trac-migration